Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20200409130434.6736-1-ardb@kernel.org> <20200409190109.GB45598@mit.edu>
In-Reply-To: <20200409190109.GB45598@mit.edu>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Thu, 9 Apr 2020 21:04:42 +0200
Message-ID: <CAMj1kXGiA3PAybR7r9tatL7WV5iU7B1OQxQok3d-JmRnhX1TnA@mail.gmail.com>
Subject: Re: [GIT PULL 0/9] EFI fixes for v5.7-rc
To:     "Theodore Y. Ts'o" <tytso@mit.edu>
Cc:     linux-efi <linux-efi@vger.kernel.org>,
        Ingo Molnar <mingo@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Arnd Bergmann <arnd@arndb.de>,
        Arvind Sankar <nivedita@alum.mit.edu>,
        Borislav Petkov <bp@suse.de>,
        Colin Ian King <colin.king@canonical.com>,
        Gary Lin <glin@suse.com>, Jiri Slaby <jslaby@suse.cz>,
        Sergey Shatunov <me@prok.pw>, Takashi Iwai <tiwai@suse.de>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, 9 Apr 2020 at 21:01, Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> On Thu, Apr 09, 2020 at 03:04:25PM +0200, Ard Biesheuvel wrote:
> > The following changes since commit 594e576d4b93b8cda3247542366b47e1b2ddc4dc:
> >
> >   efi/libstub/arm: Fix spurious message that an initrd was loaded (2020-03-29 12:08:18 +0200)
> >
> > are available in the Git repository at:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent
>
> Hi Ard,
>
> By any chance does this series fix a kexec failure which I bisected
> down to 0a67361dcdaa ("efi/x86: Remove runtime table address from
> kexec EFI setup data")?   Or if it doesn't, is this a known failure?
>

Hi Ted,

I wasn't aware of this issue, and this series will most likely not fix it.

> I'm currently building Linus's latest branch to see if it's been fixed
> since v5.6-11114-g9c94b39560c3 (which is where I first noticed it) and
> while I was waiting for v5.6-12349-g87ebc45d2d32 to finish building so
> I could test it, I noticed these patches, and so I figured I'd fire
> off this quick question.
>

I think we might be able to downright revert that patch if the
underlying assumption on my part is inaccurate, which was that the
fact that the boot code no longer uses the runtime table address
implies that there is no longer a reason to pass it.

Please involve me in the discussions on this issue.