Re: [PATCH v4 3/3] s390/crypto: Fix use of mutex in atomic context

[Harald Freudenberger <freude@linux.ibm.com>]

On 2026-08-14 14:46, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider:
> 
> Pre-existing issues:
> - [High] The patch completely misses the exact same preexisting
> invalid mutex usage in atomic context in the Protected AES (PAES) CTR
> implementation (`paes_s390.c`).
> --
> 
> --- Patch [3]: [PATCH v4 3/3] s390/crypto: Fix use of mutex in atomic
> context ---
> commit 709721b3784d3a0026753ef3b28100620270373d
> Author: Harald Freudenberger <freude@linux.ibm.com>
> 
> s390/crypto: Fix use of mutex in atomic context
> 
> This commit replaces a mutex with a binary semaphore in the s390 AES 
> CTR
> implementation. This prevents unsafe locking when the crypto routines 
> are
> called from atomic or interrupt contexts.
> 
>> diff --git a/arch/s390/crypto/aes_s390.c b/arch/s390/crypto/aes_s390.c
>> index 10561aa687c78..bd9815988c813 100644
>> --- a/arch/s390/crypto/aes_s390.c
>> +++ b/arch/s390/crypto/aes_s390.c
> [ ... ]
>> @@ -569,12 +569,13 @@ static int ctr_aes_crypt(struct skcipher_request 
>> *req)
>>  	u8 buf[AES_BLOCK_SIZE], *ctrptr;
>>  	struct skcipher_walk walk;
>>  	unsigned int n, nbytes;
>> -	int ret, locked;
>> +	bool locked;
>> +	int ret;
>> 
>>  	if (unlikely(!sctx->fc))
>>  		return fallback_skcipher_crypt(sctx, req, 0);
>> 
>> -	locked = mutex_trylock(&ctrblk_lock);
>> +	locked = down_trylock(&ctrblk_sem) == 0;
> 
> [Severity: High]
> This is a pre-existing issue, but it appears the exact same pattern 
> exists in
> the Protected AES (PAES) CTR implementation which wasn't updated here.
> 
> Looking at ctr_paes_do_crypt() in arch/s390/crypto/paes_s390.c:
> 
> 	locked = mutex_trylock(&ctrblk_lock);
> 
> Since the skcipher API can be invoked from atomic or interrupt contexts 
> (like
> network softirqs), does the PAES implementation also risk an atomic 
> context
> locking violation? Should arch/s390/crypto/paes_s390.c receive a 
> similar
> conversion to a binary semaphore?

This is addressed in another patch series for paes_s390.c