Re: backport request

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Jul 25, 2023 at 03:25:35PM +0200, Ard Biesheuvel wrote:
> On Tue, 25 Jul 2023 at 15:21, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Jul 25, 2023 at 02:51:56PM +0200, Ard Biesheuvel wrote:
> > > On Tue, 25 Jul 2023 at 14:29, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Tue, Jul 25, 2023 at 01:13:34PM +0200, Ard Biesheuvel wrote:
> > > > > Please backport commit
> > > > >
> > > > > commit 9cf42bca30e98a1c6c9e8abf876940a551eaa3d1
> > > > > Author: Ard Biesheuvel <ardb@kernel.org>
> > > > > Date:   Tue Aug 2 11:00:16 2022 +0200
> > > > >
> > > > >     efi: libstub: use EFI_LOADER_CODE region when moving the kernel in memory
> > > > >
> > > > > to all active stable trees all the way back to v5.15. I will provide a
> > > > > separate backport for v5.10, and possibly a [much] larger set of
> > > > > backports for v5.4 for EFI boot support.
> > > >
> > > > Sure, but why?  That sounds like a new feature, if you want EFI boot
> > > > support, why not just move to a newer kernel tree?  What bug is this
> > > > fixing?
> > > >
> > >
> > > Perhaps it is something that the distros just needs to carry in their
> > > forks, then.
> > >
> > > This is related to distro forks of grub and shim, and the royal mess
> > > they created on x86. We are making progress on the GRUB side to move
> > > to the much simpler and cleaner generic EFI stub support that works
> > > for x86, ARM, arm64, RISC-V and LoongArch. The problem is that the
> > > distros have a huge set of patches between them that turn shim, GRUB
> > > and the way x86 boots in a huge tangled mess, and they cannot phase
> > > those out as long as they need to support older kernels, and so they
> > > are now in a situation where they need to support all of the above.
> > >
> > > v5.4 is the only release where it is somewhat feasible to backport the
> > > changes [0] that would allow those GRUB out-of-tree hacks to be
> > > dropped. I.e., the number of backported patches is quite substantial
> > > but there are very few and minor conflicts, and the changes are
> > > confined to EFI code. Backporting this stuff from ~v5.8 to v5.4 would
> > > mean they can accelerate their phase out schedule by a year.
> > > (Actually, they asked me about v4.4 but anything older than v5.4 is
> > > really out of the question)
> > >
> > > In any case, I promised them to take a look and I did - I won't be the
> > > one pushing for this to get merged.
> >
> > I think this is up to the distros if they want to deal with this mess on
> > their older kernels.  They created it, and they want to maintain it as
> > their "value add", so let's let them earn that value :)
> >
> > So I'll not add these to any older kernels, they can use 6.1.y instead
> > if they want to.
> >
> 
> Yes, but please backport commit
> 9cf42bca30e98a1c6c9e8abf876940a551eaa3d1  nonetheless - that one is an
> obvious bug fix.

Ok, will do after this round of releases are done.

greg k-h