Re: Patch "ext4: switch to using the crc32c library" has been added to the 6.12-stable tree

Re: Patch "ext4: switch to using the crc32c library" has been added to the 6.12-stable tree

[Eric Biggers]

[+Cc linux-ext4@vger.kernel.org]

On Fri, Oct 16, 2026 at 01:13:35PM -0400, Sasha Levin wrote:
> This is a note to let you know that I've just added the patch titled
> 
>     ext4: switch to using the crc32c library
> 
> to the 6.12-stable tree which can be found at:
>     http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> 
> The filename of the patch is:
>      ext4-switch-to-using-the-crc32c-library.patch
> and it can be found in the queue-6.12 subdirectory.
> 
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable@vger.kernel.org> know about it.

Nack.  Missing prerequisite commits and didn't Cc the mailing list.

- Eric

Re: Patch "ext4: switch to using the crc32c library" has been added to the 6.12-stable tree

[Sasha Levin]

> Nack.  Missing prerequisite commits and didn't Cc the mailing list.

Dropped, thanks.

-- 
Thanks,
Sasha

Re: Patch "ext4: switch to using the crc32c library" has been added to the 6.12-stable tree

[Eric Biggers]

On Fri, Oct 16, 2026 at 11:00:21PM -0400, Sasha Levin wrote:
> > Nack.  Missing prerequisite commits and didn't Cc the mailing list.
> 
> Dropped, thanks.

Thanks.  Note that the commit message itself described the prerequisite,
and it intentionally did *not* have 'Cc stable'.  Also this was patch 16
of a 19-patch series
(https://lore.kernel.org/all/20241202010844.144356-17-ebiggers@kernel.org/),
which is discoverable from the commit itself via the lore link.

A similar example was
https://lore.kernel.org/all/20260616145143.326415700@linuxfoundation.org/.
That had the same characteristics: commit message itself described the
prerequisite, it intentionally did *not* have 'Cc stable', and it was
patch 18 of a 30-patch series.  (That one was actually applied to stable
anyway, despite two people pointing out the missing prerequisites.)

And these don't go to their subsystem mailing list, so there's limited
opportunity for people to catch these incorrect backports.

Can you help me understand how these incorrect backports get queued up
in the first place?  At least from the outside, it looks like there's
some automated process that pulls in commits needed for another to apply
cleanly, without anyone really looking at them.  (Or if LLMs are making
that decision now, then they're seemingly not being asked to evaluate
whether there are other prerequisites.)

Is there a way to opt out of this until the process can be improved?

- Eric