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

[Greg KH <gregkh@linuxfoundation.org>]

On Wed, May 13, 2026 at 10:59:34PM +0000, Eric Biggers wrote:
> On Wed, May 13, 2026 at 10:04:47AM -0700, Eric Biggers wrote:
> > > > 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.
> 
> Also I should mention that your own instructions for "reproducing" the
> conflict use 'git cherry-pick':
> 
>     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^..
> 
> When these instructions are followed, there is no conflict.  The
> "conflict" is purely because you didn't use 'git cherry-pick' yourself.

Yes, that is true, we are showing how someone else can potentially
resolve the issue.  The magic is in the line:
	# <resolve conflicts, build, test, etc.>

We issue FAILED emails for any number of reasons, we don't go into the
details of why it FAILED, otherwise we would have just too much
information here.

> So just start using 'git cherry-pick', and stop asking other people to
> do it for you when there are no conflicts, please.

That does not work in our workflow at all.  Given the huge flow of
patches, and all the different issues/errors, the odds that a simple
rename will resolve the problem is very low.  For that I can not slow
down the whole process for all submissions.

> And please start Cc'ing the mailing lists.  Linux kernel development
> isn't done in private email.

This isn't a private list, we are cc:ing the people who signed off on
the patch directly.  They are the "owners" of it.

> I would have backported the copy.fail
> fixes earlier, but I never received the FAILED emails (which I'm
> guessing you sent, but only in private email to other people), so I
> didn't know they weren't being backported...

Those patches were NOT marked for stable inclusion, so they did not get
a FAILED email at all.  We were lucky that Sasha's sweep of the tree for
"random patches that have a Fixes: tag only that look interesting"
actually caught them for a few branches.  And for those, we NEVER send a
FAILED email either, as the maintainer did not explicitly ask us for
stable inclusion, so we are not going to bother them with extra stuff.

thanks,

greg k-h