Re: backport request

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 25 Jul 2023 at 15:41, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Tue, Jul 25, 2023 at 03:25:35PM +0200, Ard Biesheuvel wrote:
> > On Tue, 25 Jul 2023 at 15:21, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> wrote:
> > > > >
> > > > > On Tue, Jul 25, 2023 at 01:13:34PM +0200, Ard Biesheuvel wrote:
> > > > > > Please backport commit
> > > > > >
> > > > > > commit 9cf42bca30e98a1c6c9e8abf876940a551eaa3d1
> > > > > > Author: Ard Biesheuvel <ardb@xxxxxxxxxx>
> > > > > > 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.
>

Actually, no - please disregard.

I confused myself here - the fix is fine, just not needed for v5.10 - v6.4.

Sorry for the noise.



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux