[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150730163102.GA19943@kroah.com>
Date: Thu, 30 Jul 2015 09:31:02 -0700
From: Greg KH <gregkh@...uxfoundation.org>
To: Matt Fleming <matt@...eblueprint.co.uk>
Cc: fupan.li@...driver.com, linux-kernel@...r.kernel.org,
fupanli@...il.com, linux-efi@...r.kernel.org,
Luis Henriques <luis.henriques@...onical.com>,
stable@...r.kernel.org
Subject: Re: [PATCH 3.10 ~ 3.14] efi: fix the efi 32bit boot failed problem
On Thu, Jul 30, 2015 at 04:04:28PM +0100, Matt Fleming wrote:
> (Add linux-efi, Luis and Greg)
>
> On Tue, 28 Jul, at 06:21:19PM, fupan.li@...driver.com wrote:
> > From: fli <fupan.li@...driver.com>
> >
> > The commit 35d5134b7d5a55e269c953096224248b9f6f72c2
> > Author: Matt Fleming <matt@...sole-pimps.org>
> > Date: Tue Apr 8 13:14:00 2014 +0100
> >
> > x86/efi: Correct EFI boot stub use of code32_start
> >
> > imported a bug, which should use the label's address instead
> > of the value stored in the label's address to caculate the
> > code32_start address.
> >
> > Signed-off-by: fli <fupan.li@...driver.com>
> > ---
> > arch/x86/boot/compressed/head_32.S | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/boot/compressed/head_32.S b/arch/x86/boot/compressed/head_32.S
> > index abb988a..3b28eff 100644
> > --- a/arch/x86/boot/compressed/head_32.S
> > +++ b/arch/x86/boot/compressed/head_32.S
> > @@ -54,7 +54,7 @@ ENTRY(efi_pe_entry)
> > call reloc
> > reloc:
> > popl %ecx
> > - subl reloc, %ecx
> > + subl $reloc, %ecx
> > movl %ecx, BP_code32_start(%eax)
> >
> > sub $0x4, %esp
>
> Woa, nice catch!
>
> The commit message could do with a little work however. In particular
> the usual way to refer to a commit is like this: commit 35d5134b7d5a
> ("x86/efi: Correct EFI boot stub use of code32_start"). And the
> Signed-off-by line should contain your full name.
>
> Luis, Greg, what is the procedure for submitting a patch that is only
> required for stable?
You don't. :)
Why isn't this an issue in newer kernel releases? Did this already get
fixed by some other patch? If so, why can't we just take that patch?
If not, why not?
I _REALLY_ don't like taking patches that are not already in Linus's
tree, as it almost always turns out to be the wrong solution.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists