Re: FAILED: patch "[PATCH] lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON" failed to apply to 6.12-stable tree

[Eric Biggers <ebiggers@kernel.org>]

On Wed, Oct 28, 2026 at 11:20:14AM -0700, Eric Biggers wrote:
> On Wed, Oct 21, 2026 at 09:48:36AM -0700, Eric Biggers wrote:
> > On Wed, Oct 21, 2026 at 08:48:08AM -0700, Eric Biggers wrote:
> > > [+Cc linux-crypto@vger.kernel.org]
> > > 
> > > On Wed, Oct 21, 2026 at 04:40:37PM +0200, gregkh@linuxfoundation.org wrote:
> > > > 
> > > > The patch below does not apply to the 6.12-stable tree.
> > > > If someone wants it applied there, or to any other stable or longterm
> > > > tree, then please email the backport, including the original git commit
> > > > id to <stable@vger.kernel.org>.
> > > 
> > > It's a clean cherry-pick, as git detects the rename of
> > > poly1305-armv8.pl.  So there should be no need to require this to be
> > > resent.  Also, missing Cc to linux-crypto.
> > > 
> > > Same for 6.12, 6.6, 6.1, 5.15, and 5.10.
> > 
> > As I've said before, the reason this keeps happening is that Greg's
> > stable scripts perform a cherry-pick by first formatting the commit as a
> > patch file with the default 3 lines of context, then applying it with
> > 'patch' using the default fuzz of 2.
> > 
> > (The second step seems to occur in the 'apply_it' script, which isn't
> > public.  But based on the observed behavior, it must be what it does.)
> > 
> > This process is buggy compared to simply using 'git cherry-pick':
> > 
> > - It has no rename detection.  Any file rename, like what happened for
> >   this commit where poly1305-armv8.pl is in different locations in
> >   different branches, results in FAILED.  This happens regularly.
> > 
> > - Incorrect backports due to only *one* line of context being
> >   considered (since 3 - 2 = 1).  For examples of this, see
> >   https://lore.kernel.org/all/20260512173933.811124271@linuxfoundation.org/
> >   and
> >   https://lore.kernel.org/all/20260515154719.961677988@linuxfoundation.org/
> > 
> >   This is easily reproducible.  For example for the first one:
> > 
> >   git checkout -d v6.12.87
> >   git cherry-pick 2909f0d4994fb4306bf116df5ccee797791fce2c
> >   git show # correct backport
> > 
> >   git checkout -d v6.12.87
> >   git format-patch -1 --no-base 2909f0d4994fb4306bf116df5ccee797791fce2c
> >   patch -p1 < 0001-usb-typec-tcpm-reset-internal-port-states-on-soft-re.patch
> >   git diff # incorrect backport that was actually sent out
> > 
> >   The second example is even worse, as there the incorrect backport was
> >   actually released.
> > 
> > Just using 'git cherry-pick', as contributors are already being asked to
> > do in the FAILED emails themselves, avoids these problems.
> > 
> > Can this please be fixed?  This outdated cherry-pick process is reducing
> > the quality of the stable releases.
> 
> Any update on this from the stable maintainers?  Requiring resends for
> clean cherry-picks is a waste of time for everyone, among other issues I
> mentioned.

Seems there's no choice but to work around the process by sending out
clean cherry picks, so I've done so.

I guess I need to start using lei as well to get stable emails for
subsystems I'm interested in as well, to work around the apparent
deprecation of the subsystem mailing lists.

As for Greg/Sasha creating incorrect backports by using 'patch' instead
of 'git cherry-pick', I guess the workaround, at least for my own
commits that I might have time to check this for, is that I need to redo
every clean cherry-pick myself and verify that what was sent by
Greg/Sasha actually matches, as Greg/Sasha's process may instead patch a
different place in the file that has the same 1 line of context.

Just seems really time consuming for everyone involved to be working
around these unnecessary issues.

- Eric