On Wed, 12 Mar 2025 at 09:16, Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> 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.
Yeah, that is what I figured. Can we *please* stop doing stupid stuff
like that for arch code, especially arch/x86, which is well looked
after? (In my personal opinion, we should not be using AUTOSEL at all,
but that seems to be a lost battle)
Especially for this patch in particular, which touches the kexec code,
which is easy to break and difficult to fix. Whether the patch applies
without breaking the build is entirely irrelevant (and even that seems
a high bar for stable trees these days). Nobody should be touching any
of that code without actually testing whether or not kexec still
works.
> 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.
>
There should not be a need for people to object to something that no
actual person ever suggested in the first place.
The only responsible way to use AUTOSEL is to make it opt-in rather
than opt-out. And I object to the idea that it is ok for someone like
Sasha to run a bot that generates lots of emails to lots of people,
and put the burden on everyone else to spend actual time and mental
effort to go over all those patches and decide whether or not they
might the stable candidates, especially without any due diligence
whatsoever regarding whether the resulting kernel still boots and runs
correctly on a system that actually exercises the updated code.
