From: Ard Biesheuvel <firstname.lastname@example.org> To: Sasha Levin <email@example.com> Cc: Linux Kernel Mailing List <firstname.lastname@example.org>, stable <email@example.com>, Jeremy Linton <firstname.lastname@example.org>, linux-efi <email@example.com> Subject: Re: [PATCH AUTOSEL 4.19 133/191] efi: honour memory reservations passed via a linux specific config table Date: Sun, 10 Nov 2019 14:16:57 +0000 Message-ID: <CAKv+Gu_Pg-j6C0iRqa8wSr+=vk3rMQ=KHFykZGNGWMfcYfAjtg@mail.gmail.com> (raw) In-Reply-To: <20191110132726.GN4787@sasha-vm> On Sun, 10 Nov 2019 at 13:27, Sasha Levin <firstname.lastname@example.org> wrote: > > On Sun, Nov 10, 2019 at 08:33:47AM +0100, Ard Biesheuvel wrote: > >On Sun, 10 Nov 2019 at 03:44, Sasha Levin <email@example.com> wrote: > >> > >> From: Ard Biesheuvel <firstname.lastname@example.org> > >> > >> [ 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 <email@example.com> > >> Signed-off-by: Ard Biesheuvel <firstname.lastname@example.org> > >> Signed-off-by: Sasha Levin <email@example.com> > > > >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.
next prev parent reply index Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <firstname.lastname@example.org> 2019-11-10 2:39 ` Sasha Levin 2019-11-10 7:33 ` Ard Biesheuvel 2019-11-10 13:27 ` Sasha Levin 2019-11-10 14:16 ` Ard Biesheuvel [this message] 2019-11-10 15:56 ` Sasha Levin 2019-11-10 16:26 ` Ard Biesheuvel 2019-11-10 18:08 ` Marc Zyngier 2019-11-10 2:39 ` [PATCH AUTOSEL 4.19 134/191] efi: Make efi_rts_work accessible to efi page fault handler Sasha Levin 2019-11-10 7:35 ` Ard Biesheuvel 2019-11-10 2:39 ` [PATCH AUTOSEL 4.19 135/191] efi/x86: Handle page faults occurring while running EFI runtime services Sasha Levin 2019-11-10 7:40 ` Ard Biesheuvel 2019-11-10 2:40 ` [PATCH AUTOSEL 4.19 191/191] x86/efi: fix a -Wtype-limits compilation warning Sasha Levin
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAKv+Gu_Pg-j6C0iRqa8wSr+=vk3rMQ=KHFykZGNGWMfcYfAjtg@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-EFI Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-efi/0 linux-efi/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-efi linux-efi/ https://lore.kernel.org/linux-efi \ email@example.com public-inbox-index linux-efi Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-efi AGPL code for this site: git clone https://public-inbox.org/public-inbox.git