From: Sasha Levin <sashal@kernel.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
stable <stable@vger.kernel.org>,
Jeremy Linton <jeremy.linton@arm.com>,
linux-efi <linux-efi@vger.kernel.org>
Subject: Re: [PATCH AUTOSEL 4.19 133/191] efi: honour memory reservations passed via a linux specific config table
Date: Sun, 10 Nov 2019 08:27:26 -0500 [thread overview]
Message-ID: <20191110132726.GN4787@sasha-vm> (raw)
In-Reply-To: <CAKv+Gu-PawCS_Wq3Hm+gm_f=6-ihXarkQqP9prkj4CLt=pAnvg@mail.gmail.com>
On Sun, Nov 10, 2019 at 08:33:47AM +0100, Ard Biesheuvel wrote:
>On Sun, 10 Nov 2019 at 03:44, Sasha Levin <sashal@kernel.org> wrote:
>>
>> From: Ard Biesheuvel <ard.biesheuvel@linaro.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 <jeremy.linton@arm.com>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>
>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:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1806766
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.
Any reason this *shouldn't* be in stable? 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.
--
Thanks,
Sasha
next prev parent reply other threads:[~2019-11-10 13:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20191110024013.29782-1-sashal@kernel.org>
2019-11-10 2:39 ` [PATCH AUTOSEL 4.19 133/191] efi: honour memory reservations passed via a linux specific config table Sasha Levin
2019-11-10 7:33 ` Ard Biesheuvel
2019-11-10 13:27 ` Sasha Levin [this message]
2019-11-10 14:16 ` Ard Biesheuvel
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 publicly 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=20191110132726.GN4787@sasha-vm \
--to=sashal@kernel.org \
--cc=ard.biesheuvel@linaro.org \
--cc=jeremy.linton@arm.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).