On Mon, Aug 25, 2025 at 04:23:59PM +0200, Mikulas Patocka wrote: > > I'd like to ask about this condition in crypto_ahash_digest: > if (ahash_req_on_stack(req) && ahash_is_async(tfm)) > return -EAGAIN; > > Can it be removed? Or, is there some reason why you can't have > asynchronous requests on the stack (such as inability of doing DMA to > virtually mapped stack)?
Right, in general you can't use stack requests for async hash because they may DMA to the request memory. > Or, should I just clear the flag CRYPTO_TFM_REQ_ON_STACK in my code? That would not work in general because of DMA. > The commit 04bfa4c7d5119ca38f8133bfdae7957a60c8b221 says that we should > clone the request with HASH_REQUEST_CLONE, but that is not usable in > dm-integrity, because dm-integrity must work even when the system is out > of memory. The idea with HASH_REQUEST_CLONE is to fall back to software hashes when the memory allocation fails. This is transparent to dm-crypt as the Crypto API will automatically switch to the fallback after the failed CLONE call. IOW you just write your code as if the CLONE will always succeed. It will simply replace the async hash with a synchronous one in the failure case. However, this doesn't even work for Harald's use case because it can't have a software fallback as the hash key is stored in hardware. Of course Harald's case doesn't do DMA either, the only reason it goes async is to wait for the hardware to become ready. So what I can do is bypass the ahash_req_on_stack for Harald's driver by changing the ahash_is_async test to something more specific about DMA. Let me write that up and I'll have something for you to test in a couple of days. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
