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

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The exact same `mutex_trylock()` in atomic context bug fixed by this patch in PAES is also present in standard AES CTR (`arch/s390/crypto/aes_s390.c`) but was left unpatched.
--

--- Patch [3]: [PATCH v2 3/6] s390/crypto: Fix use of mutex in atomic context in PAES ---
commit e6433be4cd856ce7a9d00fbe2d231629541a50c3
Author: Harald Freudenberger <[email protected]>

s390/crypto: Fix use of mutex in atomic context in PAES

This commit replaces a mutex with a binary semaphore in the PAES CTR
implementation. This prevents panics or lockdep warnings when the CTR
processing is called from atomic or interrupt contexts.

> diff --git a/arch/s390/crypto/paes_s390.c b/arch/s390/crypto/paes_s390.c
> index d075b0241f1f5..e8bbfc376ebb1 100644
> --- a/arch/s390/crypto/paes_s390.c
> +++ b/arch/s390/crypto/paes_s390.c
[ ... ]
> @@ -971,7 +972,7 @@ static int ctr_paes_do_crypt(struct s390_paes_ctx *ctx,
>  	if (rc)
>  		goto out;
>  
> -	locked = mutex_trylock(&ctrblk_lock);
> +	locked = down_trylock(&ctrblk_sem) == 0;

[Severity: High]
This isn't a bug introduced by this patch, but does the same fix need to be
applied to the standard AES CTR implementation in
arch/s390/crypto/aes_s390.c?

Looking at ctr_aes_crypt() in that file, it uses the exact same locking
pattern:

arch/s390/crypto/aes_s390.c:ctr_aes_crypt() {
    ...
    locked = mutex_trylock(&ctrblk_lock);
    ...
    if (locked)
        mutex_unlock(&ctrblk_lock);
    ...
}

Since skcipher algorithms can be called from atomic or softirq contexts
during operations like ipsec network packet processing, could this similarly
trigger a panic or lockdep warning?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3