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

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

[Eric Biggers]

[+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.

- Eric

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

[Eric Biggers]

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.

- Eric

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

[Eric Biggers]

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.

- Eric

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

[Eric Biggers]

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

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

[Greg KH]

On Wed, Oct 21, 2026 at 08:48:06AM -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.

For both of these, we have explained in the past why that is the case.

For the cherry-pick issue, we use quilt for the stable trees because it
can handle adding/moving/deleting things in any order, like is required
here.  Using a git tree does not.  So cherry-pick is not part of our
backport process because it's just not possible.

To make it possible, at each commit we would have to keep a local copy
of the current patches in a git tree, and then generate the new commit
from that, pull it out of that tree, apply it to the quilt tree, and
then go and regenerate the git tree (if needed).  In short, a mess and
would slow us down even more.

So yes, renames for "simple" things are a pain at times, it's just part
of the process.  Luckily Sasha's bot catch them quickly and provide a
backport easily in a day or so, so if you want, just rely on that.

For cc: the mailing list, no, we don't do that as it would make things
SO much noiser, and for some patches, a total mess.  We cc: everyone
involved in the original patch based on the info in the commit itself.
That's a policy decision we aren't going to change at this point in time
and attempting to add it for only one subsystem like you have asked for
here is going to be a mess.

If you care about these types of failures, just set up a lei filter to
catch them as we post these failures in public, that way no additional
mail needs to be sent.

thanks,

greg k-h

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

[Greg KH]

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.)

That script has been public for decades:
	https://github.com/gregkh/gregkh-linux/blob/master/stable/apply_it

> This process is buggy compared to simply using 'git cherry-pick':

Agreed, see my previous message, we don't use git cherry-pick for this
workflow, sorry.

thanks,

greg k-h