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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxx>
> > > >
> > > > [ 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@xxxxxxxxxx
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.
thanks,
greg k-h
