[PATCH 0/4] crypto: hisilicon - fix several issues in QM and SEC drivers

[PATCH 0/4] crypto: hisilicon - fix several issues in QM and SEC drivers

[Chenghai Huang]

This series fixes several issues in the Hisilicon QM and SEC drivers:

1.fix the devm_kcalloc() argument order in qm_pre_store_caps().
2.fix scheduling while atomic in the SEC AEAD soft fallback, which is
reachable with the backlog spinlock held.
3.fix a memory leak in hisi_qm_sort_devices() on the kzalloc() failure
path.
4.use GFP_KERNEL instead of GFP_ATOMIC in hisi_qm_memory_init(), which
runs in process context.

Wenkai Lin (4):
  crypto: hisilicon/qm - fix devm_kcalloc argument order
  crypto: hisilicon/sec2 - fix scheduling while atomic in aead soft
    fallback
  crypto: hisilicon/qm - fix memory leak in hisi_qm_sort_devices
  crypto: hisilicon/qm - fix GFP flag inconsistency in
    hisi_qm_memory_init

 drivers/crypto/hisilicon/qm.c              | 9 ++++++---
 drivers/crypto/hisilicon/sec2/sec_crypto.c | 2 +-
 2 files changed, 7 insertions(+), 4 deletions(-)

-- 
2.43.0

[PATCH 1/4] crypto: hisilicon/qm - fix devm_kcalloc argument order

[Chenghai Huang]

From: Wenkai Lin <linwenkai6@hisilicon.com>

The n and size arguments of devm_kcalloc in qm_pre_store_caps() are
swapped. Fix the order to match the kcalloc(n, size, flags) convention.

Fixes: 7c234e138c67 ("crypto: hisilicon/qm - replace devm_kzalloc with devm_kcalloc")
Signed-off-by: Wenkai Lin <linwenkai6@hisilicon.com>
Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com>
---
 drivers/crypto/hisilicon/qm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/hisilicon/qm.c b/drivers/crypto/hisilicon/qm.c
index c01966a4a33f..e915cacef5c0 100644
--- a/drivers/crypto/hisilicon/qm.c
+++ b/drivers/crypto/hisilicon/qm.c
@@ -5732,7 +5732,7 @@ static int qm_pre_store_caps(struct hisi_qm *qm)
 	size_t i, size;
 
 	size = ARRAY_SIZE(qm_cap_query_info);
-	qm_cap = devm_kcalloc(&pdev->dev, sizeof(*qm_cap), size, GFP_KERNEL);
+	qm_cap = devm_kcalloc(&pdev->dev, size, sizeof(*qm_cap), GFP_KERNEL);
 	if (!qm_cap)
 		return -ENOMEM;
 
-- 
2.43.0

[PATCH 2/4] crypto: hisilicon/sec2 - fix scheduling while atomic in aead soft fallback

[Chenghai Huang]

From: Wenkai Lin <linwenkai6@hisilicon.com>

sec_aead_soft_crypto() allocates the sub-request with GFP_KERNEL, which
may sleep.  This is safe when called directly from sec_aead_crypto()
(process context), but the function is also reachable through the
backlog drain path.

When an AEAD request sits in the backlog queue and qp_send_message()
returns a non-EBUSY error, the backlog is drained in software while
the backlog spinlock is still held. The GFP_KERNEL allocation inside
aead_request_alloc() can then schedule out, triggering scheduling
while atomic.

Fix it by switching the allocation to GFP_ATOMIC so it is safe in both
the process-context path and the spinlock-held backlog drain path.

Fixes: 0a2a464f8631 ("crypto: hisilicon/sec - fix the aead software fallback for engine")
Signed-off-by: Wenkai Lin <linwenkai6@hisilicon.com>
Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com>
---
 drivers/crypto/hisilicon/sec2/sec_crypto.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/hisilicon/sec2/sec_crypto.c b/drivers/crypto/hisilicon/sec2/sec_crypto.c
index 0a2f7c8b44fc..bbb6826ab256 100644
--- a/drivers/crypto/hisilicon/sec2/sec_crypto.c
+++ b/drivers/crypto/hisilicon/sec2/sec_crypto.c
@@ -2533,7 +2533,7 @@ static int sec_aead_soft_crypto(struct sec_ctx *ctx,
 	struct aead_request *subreq;
 	int ret;
 
-	subreq = aead_request_alloc(a_ctx->fallback_aead_tfm, GFP_KERNEL);
+	subreq = aead_request_alloc(a_ctx->fallback_aead_tfm, GFP_ATOMIC);
 	if (!subreq)
 		return -ENOMEM;
 
-- 
2.43.0

[PATCH 3/4] crypto: hisilicon/qm - fix memory leak in hisi_qm_sort_devices

[Chenghai Huang]

From: Wenkai Lin <linwenkai6@hisilicon.com>

hisi_qm_sort_devices() allocates a struct hisi_qm_resource for each
QM device and inserts it into one of two local lists (non_full_list
or full_list).  If kzalloc() fails mid-loop, the function returns
-ENOMEM immediately without freeing the resources already inserted
into the local lists.

Because the splice into the caller's @head list happens only after
the loop completes, the caller's free_list(&head) cannot reclaim
them, so the already-allocated res entries are lost.

Fix by freeing both local lists before returning -ENOMEM.

Fixes: 2a75decec119 ("crypto: hisilicon/qm - optimize device selection priority based on queue ref count and NUMA distance")
Signed-off-by: Wenkai Lin <linwenkai6@hisilicon.com>
Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com>
---
 drivers/crypto/hisilicon/qm.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/hisilicon/qm.c b/drivers/crypto/hisilicon/qm.c
index e915cacef5c0..0448c68dbde4 100644
--- a/drivers/crypto/hisilicon/qm.c
+++ b/drivers/crypto/hisilicon/qm.c
@@ -3846,8 +3846,11 @@ static int hisi_qm_sort_devices(int node, struct list_head *head,
 			dev_node = 0;
 
 		res = kzalloc_obj(*res);
-		if (!res)
+		if (!res) {
+			free_list(&non_full_list);
+			free_list(&full_list);
 			return -ENOMEM;
+		}
 
 		res->qm = qm;
 		res->distance = node_distance(dev_node, node);
-- 
2.43.0

[PATCH 4/4] crypto: hisilicon/qm - fix GFP flag inconsistency in hisi_qm_memory_init

[Chenghai Huang]

From: Wenkai Lin <linwenkai6@hisilicon.com>

hisi_qm_memory_init() is called from hisi_qm_init() (process context)
but uses GFP_ATOMIC for dma_alloc_coherent().  The equivalent
allocation in qm_alloc_xqc_dma() uses GFP_KERNEL.

GFP_ATOMIC cannot reclaim or compact memory, so it fails more easily
under memory pressure even though sleeping is allowed here.  Switch
to GFP_KERNEL, which is safe in process context and consistent with
qm_alloc_xqc_dma().

Fixes: 5308f6600a39 ("crypto: hisilicon - QM memory management optimization")
Signed-off-by: Wenkai Lin <linwenkai6@hisilicon.com>
Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com>
---
 drivers/crypto/hisilicon/qm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/hisilicon/qm.c b/drivers/crypto/hisilicon/qm.c
index 0448c68dbde4..a5593ee3889c 100644
--- a/drivers/crypto/hisilicon/qm.c
+++ b/drivers/crypto/hisilicon/qm.c
@@ -6067,7 +6067,7 @@ static int hisi_qm_memory_init(struct hisi_qm *qm)
 			QMC_ALIGN(sizeof(struct qm_sqc) * qm->qp_num) +
 			QMC_ALIGN(sizeof(struct qm_cqc) * qm->qp_num);
 	qm->qdma.va = dma_alloc_coherent(dev, qm->qdma.size, &qm->qdma.dma,
-					 GFP_ATOMIC);
+					 GFP_KERNEL);
 	dev_dbg(dev, "allocate qm dma buf size=%zx)\n", qm->qdma.size);
 	if (!qm->qdma.va) {
 		ret = -ENOMEM;
-- 
2.43.0

Re: [PATCH 2/4] crypto: hisilicon/sec2 - fix scheduling while atomic in aead soft fallback

[Herbert Xu]

On Fri, Sep 11, 2026 at 06:29:40PM +0800, Chenghai Huang wrote:
> From: Wenkai Lin <linwenkai6@hisilicon.com>
> 
> sec_aead_soft_crypto() allocates the sub-request with GFP_KERNEL, which
> may sleep.  This is safe when called directly from sec_aead_crypto()
> (process context), but the function is also reachable through the
> backlog drain path.
> 
> When an AEAD request sits in the backlog queue and qp_send_message()
> returns a non-EBUSY error, the backlog is drained in software while
> the backlog spinlock is still held. The GFP_KERNEL allocation inside
> aead_request_alloc() can then schedule out, triggering scheduling
> while atomic.
> 
> Fix it by switching the allocation to GFP_ATOMIC so it is safe in both
> the process-context path and the spinlock-held backlog drain path.
> 
> Fixes: 0a2a464f8631 ("crypto: hisilicon/sec - fix the aead software fallback for engine")
> Signed-off-by: Wenkai Lin <linwenkai6@hisilicon.com>
> Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com>
> ---
>  drivers/crypto/hisilicon/sec2/sec_crypto.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/crypto/hisilicon/sec2/sec_crypto.c b/drivers/crypto/hisilicon/sec2/sec_crypto.c
> index 0a2f7c8b44fc..bbb6826ab256 100644
> --- a/drivers/crypto/hisilicon/sec2/sec_crypto.c
> +++ b/drivers/crypto/hisilicon/sec2/sec_crypto.c
> @@ -2533,7 +2533,7 @@ static int sec_aead_soft_crypto(struct sec_ctx *ctx,
>  	struct aead_request *subreq;
>  	int ret;
>  
> -	subreq = aead_request_alloc(a_ctx->fallback_aead_tfm, GFP_KERNEL);
> +	subreq = aead_request_alloc(a_ctx->fallback_aead_tfm, GFP_ATOMIC);

Please use SYNC_AEAD_REQUEST_ON_STACK for the fallback.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 2/4] crypto: hisilicon/sec2 - fix scheduling while atomic in aead soft fallback

[Herbert Xu]

On Wed, Sep 23, 2026 at 05:55:43PM +0800, huangchenghai wrote:
>
> I try to use SYNC_AEAD_REQUEST_ON_STACK instead, but it does not
> work here: crypto_alloc_sync_aead() enforces a MAX_SYNC_AEAD_REQSIZE
> limit of 384 bytes, and several composite AEAD algorithms supported
> by sec2 (e.g. ccm(sm4), authenc(hmac(sha512),cbc(aes))) have a larger
> reqsize, so the sync tfm allocation fails with -EINVAL.

How big are these algorithms, is there any reason why we can't
increase MAX_SYNC_AEAD_REQSIZE to accommodate them?

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 2/4] crypto: hisilicon/sec2 - fix scheduling while atomic in aead soft fallback

[Herbert Xu]

On Wed, Sep 30, 2026 at 09:22:31AM +0800, huangchenghai wrote:
>
> The sizes vary by algorithm. The worst case in the sec2 driver is
> authenc(hmac(sha512),cbc(aes)) at ~568 bytes, mainly due to reqoff = 2 *
> SHA512_DIGEST_SIZE plus the embedded HMAC ahash request. The ccm variants
> are ~468 bytes since crypto_ccm_req_priv_ctx embeds a full ahash_request
> union along with two 3-element scatterlist arrays. gcm(aes) and gcm(sm4)
> are ~288 bytes and fit within the current 384.
> 
> The only concern with bumping MAX_SYNC_AEAD_REQSIZE is stack usage, since
> SYNC_AEAD_REQUEST_ON_STACK allocates on the 16KB kernel stack. But the
> fallback path is shallow -- driver -> crypto_aead_encrypt -> template
> internals -- so the additional stack usage should be fine.
> 
> Would increasing MAX_SYNC_AEAD_REQSIZE to 1024 be acceptable? That covers
> all current algorithms with some headroom. Per-call stack allocation would
> be roughly 1KB, which seems reasonable for this path.

Thanks for looking into this.

My preference would be to change authenc to store everything on
the stack *if* both skcipher and the hash are actually sync.

Let me write something up.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt