Re: [GIT PULL 0/1] EFI mixed mode fix for v4.18

[Ingo Molnar]

* Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote:

> On 11 July 2018 at 13:14, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
> >
> > * Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote:
> >
> >> On 11 July 2018 at 12:13, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
> >> >
> >> > * Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote:
> >> >
> >> >> The following changes since commit 1e4b044d22517cae7047c99038abb444423243ca:
> >> >>
> >> >>   Linux 4.18-rc4 (2018-07-08 16:34:02 -0700)
> >> >>
> >> >> are available in the Git repository at:
> >> >>
> >> >>   git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent
> >> >>
> >> >> for you to fetch changes up to d7f2e972e702d329fe11d6956df99dfc31211c25:
> >> >>
> >> >>   efi/x86: remove pointless call to PciIo->Attributes() (2018-07-11 10:52:46 +0200)
> >> >>
> >> >> ----------------------------------------------------------------
> >> >> A single fix for the x86 PCI I/O protocol handling code that got
> >> >> broken for mixed mode (64-bit Linux/x86 on 32-bit UEFI) after a
> >> >> fix was applied in -rc2 to fix it for ordinary 64-bit Linux/x86.
> >> >
> >> > Just curious, because it's unclear from the changelog, what was the symptom, a
> >> > boot hang, instant reboot, or some other misbehavior?
> >>
> >> Hans reported that his mixed mode tablet would not boot at all any
> >> more, but enter a reboot loop without any logs printed by the kernel.
> >>
> >> > Also, what's the scope of
> >> > the fix: were all 64-bit on 32-bit UEFI mixed-mode bootups affected, or only a
> >> > certain subset?
> >> >
> >>
> >> Any mixed mode system with PCI is likely to be affected. I have added
> >> a QEMU mixed mode config to my boot test environment to catch errors
> >> like this one.
> >
> > Ok, I've added this information to the commit - will be useful to backporters,
> > to judge the severity of the bug fixed.
> >
> 
> Perhaps it wasn't clear from the commit log that only v4.18-rc2 and
> later is affected by the mixed mode issue, since that is when a fix
> for ordinary 64-bit x86 was applied that affected v4.18-rc1.

Ah, ok. Still, if for whatever reason the commit that introduced the problem is 
backported, this one will be too. The chain of sha1's seemed rather long, so 
there's a chance for that.

> However, the EFI stub code is not expected to expand that much, and so for the 
> time being, I'm fine with a combination of review and rigorous testing

Fair enough!

Thanks,

	Ingo