[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aQSDLpD2LXlqILku@gondor.apana.org.au>
Date: Fri, 31 Oct 2025 17:36:46 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: T Pratham <t-pratham@...com>
Cc: "David S. Miller" <davem@...emloft.net>,
Manorit Chawdhry <m-chawdhry@...com>,
Kamlesh Gurudasani <kamlesh@...com>,
Shiva Tripathi <s-tripathi1@...com>,
Kavitha Malarvizhi <k-malarvizhi@...com>,
Vishal Mahaveer <vishalm@...com>,
Praneeth Bajjuri <praneeth@...com>, linux-crypto@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 2/4] crypto: ti - Add support for AES-CTR in DTHEv2
driver
On Wed, Oct 22, 2025 at 11:15:40PM +0530, T Pratham wrote:
>
> + if (ctx->aes_mode == DTHE_AES_CTR) {
> + /*
> + * CTR mode can operate on any input length, but the hardware
> + * requires input length to be a multiple of the block size.
> + * We need to handle the padding in the driver.
> + */
> + if (req->cryptlen % AES_BLOCK_SIZE) {
> + /* Need to create a new SG list with padding */
> + pad_len = ALIGN(req->cryptlen, AES_BLOCK_SIZE) - req->cryptlen;
> + struct scatterlist *sg;
> +
> + src = kmalloc_array((src_nents + 1), sizeof(*src), GFP_KERNEL);
You can't allocate memory on the data path. The request might have
been issued by the storage layer and doing a GFP_KERNEL allocation
here risks dead-lock.
Failing the allocation is also not good.
Ideally you should make the hardware deal with the multiple of block
size data, and then handle the trailer in your driver.
But if it's too hard just send the whole thing to the fallback.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists