On Sun, 10 Nov 2019 at 13:27, Sasha Levin <sashal@xxxxxxxxxx> wrote: > > On Sun, Nov 10, 2019 at 08:33:47AM +0100, Ard Biesheuvel wrote: > >On Sun, 10 Nov 2019 at 03:44, Sasha Levin <sashal@xxxxxxxxxx> wrote: > >> > >> From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > >> > >> [ Upstream commit 71e0940d52e107748b270213a01d3b1546657d74 ] > >> > >> In order to allow the OS to reserve memory persistently across a > >> kexec, introduce a Linux-specific UEFI configuration table that > >> points to the head of a linked list in memory, allowing each kernel > >> to add list items describing memory regions that the next kernel > >> should treat as reserved. > >> > >> This is useful, e.g., for GICv3 based ARM systems that cannot disable > >> DMA access to the LPI tables, forcing them to reuse the same memory > >> region again after a kexec reboot. > >> > >> Tested-by: Jeremy Linton <jeremy.linton@xxxxxxx> > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > >> Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx> > > > >NAK > > > >This doesn't belong in -stable, and I'd be interested in understanding > >how this got autoselected, and how I can prevent this from happening > >again in the future. > > It was selected because it's part of a fix for a real issue reported by > users: > For my understanding, are you saying your AI is reading launchpad bug reports etc? Because it is marked AUTOSEL. > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1806766 > That pages mentions """ 2 upstream patch series are required to fix this: https://<email address hidden>/msg10328.html Which provides an EFI facility consumed by: https://lkml.org/lkml/2018/9/21/1066 There were also some follow-on fixes to deal with ARM-specific problems associated with this usage: https://www.spinics.net/lists/arm-kernel/msg685751.html """ and without the other patches, we only add bugs and don't fix any. > Besides ubuntu, it is also carried by: > > SUSE: https://www.suse.com/support/update/announcement/2019/suse-su-20191530-1/ > CentOS: https://koji.mbox.centos.org/koji/buildinfo?buildID=4558 > > As a way to resolve the reported bug. > Backporting a feature/fix like this requires careful consideration of the patches involved, and doing actual testing on hardware. > Any reason this *shouldn't* be in stable? Yes. By itself, it causes crashes at early boot and does not actually solve the problem. > I'm aware that there might be > dependencies that are not obvious to me, but the solution here is to > take those dependencies as well rather than ignore the process > completely. > This is not a bugfix. kexec/kdump never worked correctly on the hardware involved, and backporting a feature like that goes way beyond what I am willing to accept for stable backports affecting the EFI subsystem.
