[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 2 Feb 2020 10:32:11 +0100
From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: Jörg Otte <jrg.otte@...il.com>,
Dan Williams <dan.j.williams@...el.com>,
Ard Biesheuvel <ardb@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: EFI boot crash regression (was: Re: 5.6-### doesn't boot)
On Sun, 2 Feb 2020 at 10:22, Ingo Molnar <mingo@...nel.org> wrote:
>
>
> * Ard Biesheuvel <ard.biesheuvel@...aro.org> wrote:
>
> > Hello Jörg,
> >
> > Could you please try whether the change below fixes the issue?
> >
> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> > index 59f7f6d60cf6..ae923ee8e2b4 100644
> > --- a/arch/x86/platform/efi/efi.c
> > +++ b/arch/x86/platform/efi/efi.c
> > @@ -308,7 +308,7 @@ static void __init efi_clean_memmap(void)
> > .phys_map = efi.memmap.phys_map,
> > .desc_version = efi.memmap.desc_version,
> > .desc_size = efi.memmap.desc_size,
> > - .size = data.desc_size * (efi.memmap.nr_map - n_removal),
> > + .size = efi.memmap.desc_size * (efi.memmap.nr_map - n_removal),
> > .flags = 0,
>
> Oh, I actually noticed this one, but convinced myself that it's correct,
> because GCC didn't warn about uninitialized data.
>
> But maybe in this weird case data.desc_size as used within its own
> initializer is zero?
>
Something like that, yes. Note that size and desc_size appear in
opposite order in the struct definition, and this may also affect how
the compiler handles this.
Powered by blists - more mailing lists