Re: FAILED: patch "[PATCH] lib/crypto: mpi: Fix integer underflow in" failed to apply to 6.1-stable tree

Re: FAILED: patch "[PATCH] lib/crypto: mpi: Fix integer underflow in" failed to apply to 6.1-stable tree

[Eric Biggers]

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

On Tue, May 12, 2026 at 04:01:23PM +0200, gregkh@linuxfoundation.org wrote:
> 
> The patch below does not apply to the 6.1-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>.
> 
> To reproduce the conflict and resubmit, you may use the following commands:
> 
> git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
> git checkout FETCH_HEAD
> git cherry-pick -x 8c2f1288250a90a4b5cabed5d888d7e3aeed4035
> # <resolve conflicts, build, test, etc.>
> git commit -s
> git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026051223-undercoat-reps-6626@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
> 
> Possible dependencies:

A couple issues.  First, this email wasn't sent to the subsystem's
mailing list (linux-crypto@vger.kernel.org in this case).  That greatly
reduces the number of people who are made aware that this didn't get
automatically backported.

Second, the upstream commit cherry-picks to 6.1, 5.15, and 5.10 without
conflict.  (The file being changed was renamed between 6.1 and 6.6, but
'git cherry-pick' handles that automatically.)

I don't know what you're doing exactly that caused it to be
unnecessarily marked as FAILED.  But whatever it is, it's not working,
and it is causing backports to be missed.

- Eric

Re: FAILED: patch "[PATCH] lib/crypto: mpi: Fix integer underflow in" failed to apply to 6.1-stable tree

[Greg KH]

On Tue, May 12, 2026 at 07:51:30PM -0700, Eric Biggers wrote:
> [+Cc linux-crypto@vger.kernel.org]
> 
> On Tue, May 12, 2026 at 04:01:23PM +0200, gregkh@linuxfoundation.org wrote:
> > 
> > The patch below does not apply to the 6.1-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>.
> > 
> > To reproduce the conflict and resubmit, you may use the following commands:
> > 
> > git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
> > git checkout FETCH_HEAD
> > git cherry-pick -x 8c2f1288250a90a4b5cabed5d888d7e3aeed4035
> > # <resolve conflicts, build, test, etc.>
> > git commit -s
> > git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026051223-undercoat-reps-6626@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
> > 
> > Possible dependencies:
> 
> A couple issues.  First, this email wasn't sent to the subsystem's
> mailing list (linux-crypto@vger.kernel.org in this case).  That greatly
> reduces the number of people who are made aware that this didn't get
> automatically backported.

We never send out these FAILED emails to the mailing lists, as that
would make just even more noise.  It's always been this way, sorry.

> Second, the upstream commit cherry-picks to 6.1, 5.15, and 5.10 without
> conflict.  (The file being changed was renamed between 6.1 and 6.6, but
> 'git cherry-pick' handles that automatically.)
> 
> I don't know what you're doing exactly that caused it to be
> unnecessarily marked as FAILED.  But whatever it is, it's not working,
> and it is causing backports to be missed.

We don't use git for cherry-picking as we have a patch queue, so renames
will often times fail, like it did here.  This has always been the case
in the decades we have been running the stable kernels :)

thanks,

greg k-h

Re: FAILED: patch "[PATCH] lib/crypto: mpi: Fix integer underflow in" failed to apply to 6.1-stable tree

[Eric Biggers]

On Wed, May 13, 2026 at 12:34:38PM +0200, Greg KH wrote:
> On Tue, May 12, 2026 at 07:51:30PM -0700, Eric Biggers wrote:
> > [+Cc linux-crypto@vger.kernel.org]
> > 
> > On Tue, May 12, 2026 at 04:01:23PM +0200, gregkh@linuxfoundation.org wrote:
> > > 
> > > The patch below does not apply to the 6.1-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>.
> > > 
> > > To reproduce the conflict and resubmit, you may use the following commands:
> > > 
> > > git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
> > > git checkout FETCH_HEAD
> > > git cherry-pick -x 8c2f1288250a90a4b5cabed5d888d7e3aeed4035
> > > # <resolve conflicts, build, test, etc.>
> > > git commit -s
> > > git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026051223-undercoat-reps-6626@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
> > > 
> > > Possible dependencies:
> > 
> > A couple issues.  First, this email wasn't sent to the subsystem's
> > mailing list (linux-crypto@vger.kernel.org in this case).  That greatly
> > reduces the number of people who are made aware that this didn't get
> > automatically backported.
> 
> We never send out these FAILED emails to the mailing lists, as that
> would make just even more noise.  It's always been this way, sorry.

Yes, this has been a problem for a long time, resulting in lots of
missed backports including the copy.fail ones.  It's time for you to fix
your process.

> > Second, the upstream commit cherry-picks to 6.1, 5.15, and 5.10 without
> > conflict.  (The file being changed was renamed between 6.1 and 6.6, but
> > 'git cherry-pick' handles that automatically.)
> > 
> > I don't know what you're doing exactly that caused it to be
> > unnecessarily marked as FAILED.  But whatever it is, it's not working,
> > and it is causing backports to be missed.
> 
> We don't use git for cherry-picking as we have a patch queue, so renames
> will often times fail, like it did here.  This has always been the case
> in the decades we have been running the stable kernels :)

Again, this has been a problem for a long time, and it's time for you to
fix your process.  You can still have the patch queue; just use git for
the actual cherry-pick.

- Eric