On Wed, Feb 12, 2025 at 12:17:46PM +0100, Harald Freudenberger wrote: > > There are other downsides with the asynch implementations: > They are much more complex and thus expensive and - how the hell can a > test cover all the code branches? I think rather than writing an ahash algorithm from scratch, this could be done in a way similar to the simd wrapper. In fact, forget about phmac for the moment, and please fix the one that's already in the kernel: paes. Under the simd model, you turn paes into an internal algorithm that is always synchronous. In the exceptional case, you return an error so that the wrapper can then enter the async path. The wrapper handles all the complexities of the async path and hides it from the actual paes code. > Next is the thing with the CRYPTO_ALG_ALLOCATES_MEMORY flag. If I > want to have a hash implementation usable for dm-integrity the alg > implementation must NOT set this flag and must not allocate any memory > during crypto operations (includung setkey()). As of now I am still not > through with the phmac code for this. And I only have a faint idea on > how to implement this on the pkey and maybe zcrypt code... Why do you need to allocate memory? If anything ahash makes this slightly easier since you can allocate your own memory beforehand through the request object. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
