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@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.
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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
