Re: [PATCH 6.12.y 4/4] crypto: x86/aegis - Fix sleeping when disallowed on PREEMPT_RT

[Eric Biggers <ebiggers@kernel.org>]

On Thu, Aug 21, 2025 at 11:56:19PM -0400, Sasha Levin wrote:
> On Thu, Aug 21, 2025 at 11:39:51PM -0400, Eric Biggers wrote:
> > On Thu, Aug 21, 2025 at 11:28:56PM -0400, Sasha Levin wrote:
> > > On Thu, Aug 21, 2025 at 11:23:04PM -0400, Eric Biggers wrote:
> > > > On Thu, Aug 21, 2025 at 11:06:17PM -0400, Sasha Levin wrote:
> > > > > From: Eric Biggers <ebiggers@kernel.org>
> > > > >
> > > > > [ Upstream commit c7f49dadfcdf27e1f747442e874e9baa52ab7674 ]
> > > > >
> > > > > skcipher_walk_done() can call kfree(), which takes a spinlock, which
> > > > > makes it incorrect to call while preemption is disabled on PREEMPT_RT.
> > > > > Therefore, end the kernel-mode FPU section before calling
> > > > > skcipher_walk_done(), and restart it afterwards.
> > > > >
> > > > > Moreover, pass atomic=false to skcipher_walk_aead_encrypt() instead of
> > > > > atomic=true.  The point of atomic=true was to make skcipher_walk_done()
> > > > > safe to call while in a kernel-mode FPU section, but that does not
> > > > > actually work.  So just use the usual atomic=false.
> > > > >
> > > > > Fixes: 1d373d4e8e15 ("crypto: x86 - Add optimized AEGIS implementations")
> > > > > Cc: stable@vger.kernel.org
> > > > > Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> > > > > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> > > > > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > > > > ---
> > > > >  arch/x86/crypto/aegis128-aesni-glue.c | 8 ++++++--
> > > > >  1 file changed, 6 insertions(+), 2 deletions(-)
> > > >
> > > > 1. Missing Cc of the relevant mailing lists
> > > > 2. Missing cover letter
> > > 
> > > This was sent following the instructions in the FAILED: email generated by
> > > Greg. If you feel its insufficient, take it up with him.
> > 
> > You're one of the stable maintainers.  You can't just deflect and claim
> > this is not your problem.
> 
> We perform different parts of the process. I don't send FAILED: mails out, I
> don't have control over what Greg sends out. If you feel that the recipient
> list is insufficient then Greg should be in the loop - don't take it out on me.
> 
> These mails looked the same for years (decade+?), if for some reason you think
> that a cover letter or an expanded cc list would be useful to have, then you
> can just suggest it - no need to berate me for not sending one.

I've given this same feedback many times already.

> > > > 3. Missing base-commit, and doesn't apply to stable/linux-6.16.y
> > > 
> > > As the subject line indicates, this applies on 6.12, not 6.16.
> > > 
> > > > 4. Two different series were sent out, both containing this patch
> > > 
> > > You might have missed that they're for different trees?
> > > 
> > 
> > Sorry, I meant to write 6.12.  6.12 was indeed what I tried to apply it
> > to, and it failed.  And there are two series for 6.12, see
> > https://lore.kernel.org/stable/20250822030632.1053504-4-sashal@kernel.org
> > and
> > https://lore.kernel.org/stable/20250822030617.1053172-4-sashal@kernel.org/
> 
> Yup, those are replies to two different FAILED emails for two different
> patches that failed to backport.

But why send a separate series for each one, with duplicate patches
across the different series?  That makes no sense.

> Could you share the conflict you've observed? Both series applied cleanly to
> stable/linux-6.12.y for me.

Try:

    b4 am https://lore.kernel.org/stable/20250822030632.1053504-1-sashal@kernel.org/

It looks like the problem may be that b4 picks up the patch from the
FAILED email as a patch in the series.

Please make sure that the way you're sending out patch series is
compatible with b4, as reviewers often rely on that to download them.

- Eric