On Wed, 2025-03-12 at 09:16 +0100, Greg Kroah-Hartman wrote:
On Wed, Mar 12, 2025 at 08:54:52AM +0100, Ard Biesheuvel wrote:
On Wed, 12 Mar 2025 at 08:47, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Tue, Mar 11, 2025 at 04:45:26PM +0100, David Woodhouse wrote:
On Thu, 2025-02-13 at 15:24 +0100, Greg Kroah-Hartman wrote:
6.13-stable review patch. If anyone has any objections, please let me know.
From: David Woodhouse dwmw@amazon.co.uk
[ Upstream commit 4b5bc2ec9a239bce261ffeafdd63571134102323 ]
Now that the following fix:
d0ceea662d45 ("x86/mm: Add _PAGE_NOPTISHADOW bit to avoid updating userspace page tables")
stops kernel_ident_mapping_init() from scribbling over the end of a 4KiB PGD by assuming the following 4KiB will be a userspace PGD, there's no good reason for the kexec PGD to be part of a single 8KiB allocation with the control_code_page.
( It's not clear that that was the reason for x86_64 kexec doing it that way in the first place either; there were no comments to that effect and it seems to have been the case even before PTI came along. It looks like it was just a happy accident which prevented memory corruption on kexec. )
Either way, it definitely isn't needed now. Just allocate the PGD separately on x86_64, like i386 already does.
No objection (which is just as well given how late I am in replying) but I'm just not sure *why*. This doesn't fix a real bug; it's just a cleanup.
Does this mean I should have written my original commit message better, to make it clearer that this *isn't* a bugfix?
Yes, that's why it was picked up.
The patch has no fixes: tag and no cc:stable. The burden shouldn't be on the patch author to sprinkle enough of the right keywords over the commit log to convince the bot that this is not a suitable stable candidate, just because it happens to apply without conflicts.
The burden is not there to do that, this came in from the AUTOSEL stuff. It was sent to everyone on Jan 26: https://lore.kernel.org/r/20250126150720.961959-3-sashal@kernel.org so there was 1 1/2 weeks chance to say something before Sasha committed it to the stable queue. Then it was sent out again here in the -rc releases for review, for anyone to object to.
So there was 3 different times someone could have said "no, this isn't ok for stable inclusion" before it was merged. And even if that's not enough, I'll be glad to revert it if it wasn't ok to be merged at any time afterward.
FWIW I don't think there's any need to revert it; it's fine. Just not entirely necessary. I did see it in January but I was travelling so I didn't get past briefly wondering *why* it was being picked up; I thought perhaps one of the x86 maintainers had actually chosen to do so.
If I'd *objected*, I'd have found the time to do so then.