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

[Herbert Xu <herbert@gondor.apana.org.au>]

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