All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Harald Freudenberger" <freude@linux.ibm.com>
Cc: "Christian Borntraeger" <borntraeger@linux.ibm.com>,
	linux-s390@vger.kernel.org, "Vasily Gorbik" <gor@linux.ibm.com>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>
Subject: Re: [PATCH v4 3/7] s390/crypto: Fix use of mutex in atomic context in PAES
Date: Wed, 19 Aug 2026 09:27:22 +0000	[thread overview]
Message-ID: <20260819092722.79B4A1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260819091734.7331-4-freude@linux.ibm.com>

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

Pre-existing issues:
- [High] The standard AES CTR implementation uses `mutex_trylock()` and `mutex_unlock()` in a context that may be atomic, which violates core kernel locking rules.
--

--- Patch [3]: [PATCH v4 3/7] s390/crypto: Fix use of mutex in atomic context in PAES ---
commit d6ba4976a19245fd83ba5c797399a6bd57d986bb
Author: Harald Freudenberger <freude@linux.ibm.com>

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

The PAES CTR implementation used a mutex to lock one page of exclusive
memory for fast CTR processing. This commit replaces the mutex with a
binary semaphore, since a mutex is not safe to use in atomic or interrupt
context.

> 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
[ ... ]
> @@ -45,7 +45,7 @@ module_param_named(clrkey, pkey_clrkey_allowed, bool, 0444);
>  MODULE_PARM_DESC(clrkey, "Allow clear key material (default N)");
>  
>  static u8 *ctrblk;
> -static DEFINE_MUTEX(ctrblk_lock);
> +static DEFINE_SEMAPHORE(ctrblk_sem, 1);

[Severity: High]
This is a pre-existing issue, but does the standard AES implementation in
arch/s390/crypto/aes_s390.c suffer from this exact same problem?

Looking at ctr_aes_crypt() in arch/s390/crypto/aes_s390.c:

	locked = mutex_trylock(&ctrblk_lock);

	ret = skcipher_walk_virt(&walk, req, false);
	while ((nbytes = walk.nbytes) >= AES_BLOCK_SIZE) {
	...
	}
	if (locked)
		mutex_unlock(&ctrblk_lock);

Network traffic processing (e.g., IPsec) executes SKCIPHER operations from
a softirq context. Unlocking a mutex in an interrupt context triggers a
kernel panic or BUG on PREEMPT_RT kernels, and lockdep warnings on
standard kernels.

Since this patch successfully fixes the issue for PAES, should a similar
fix be applied to arch/s390/crypto/aes_s390.c?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260819091734.7331-1-freude@linux.ibm.com?part=3

  reply	other threads:[~2026-08-19  9:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-19  9:17 [PATCH v4 0/7] Fixes and rework for paes_s390 and phmac_s390 Harald Freudenberger
2026-08-19  9:17 ` [PATCH v4 1/7] s390/crypto: Fix return code handling at skcipher_walk_done in PAES algorithms Harald Freudenberger
2026-08-19  9:31   ` sashiko-bot
2026-08-19  9:17 ` [PATCH v4 2/7] s390/crypto: Fix missing scrub of temp buffers with PAES algorithm Harald Freudenberger
2026-08-19  9:30   ` sashiko-bot
2026-08-19  9:17 ` [PATCH v4 3/7] s390/crypto: Fix use of mutex in atomic context in PAES Harald Freudenberger
2026-08-19  9:27   ` sashiko-bot [this message]
2026-08-19  9:17 ` [PATCH v4 4/7] s390/crypto: Fix missing cra_flags in paes_s390 Harald Freudenberger
2026-08-19  9:22   ` sashiko-bot
2026-08-19  9:17 ` [PATCH v4 5/7] s390/crypto: Fix handling of EBUSY in PAES when req is pushed to crypto engine Harald Freudenberger
2026-08-19  9:30   ` sashiko-bot
2026-08-19  9:47   ` Holger Dengler
2026-08-19  9:17 ` [PATCH v4 6/7] s390/crypto: Fix handling of EBUSY in PHMAC " Harald Freudenberger
2026-08-19  9:37   ` sashiko-bot
2026-08-19  9:17 ` [PATCH v4 7/7] s390/crypto: Fix wrong return code to engine in asynch callbacks Harald Freudenberger
2026-08-19  9:28   ` sashiko-bot
2026-08-19 10:00   ` Holger Dengler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260819092722.79B4A1F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=freude@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.