On Tue, Jun 04, 2024 at 11:42:20AM -0700, Eric Biggers wrote:

This doesn't make any sense, though.  First, the requests need to be enqueued
for the task, but crypto_ahash_finup() would only have the ability to enqueue it
in a queue associated with the tfm, which is shared by many tasks.  So it can't

OK I screwed up that one.  But that's not hard to fix.  We could
simply add request chaining:

	ahash_request_chain(req1, req2);
	ahash_request_chain(req2, req3);
	...
	ahash_request_chain(reqn1, reqn);

	err = crypto_ahash_finup(req1);

actually work unless the tfm maintained a separate queue for each task, which
would be really complex.  Second, it adds a memory allocation per block which is
very undesirable.  You claim that it's needed anyway, but actually it's not;
with my API there is only one initial hash state regardless of how high the
interleaving factor is.  In fact, if multiple initial states were allowed,

Sure you don't need it for two interleaved requests.  But as you
scale up to 16 and beyond, surely at some point you're going to
want to move the hash states off the stack.

multibuffer hashing would become much more complex because the underlying
algorithm would need to validate that these different states are synced up.  My
proposal is much simpler and avoids all this unnecessary overhead.

We could simply state that these chained requests must be on block
boundaries, similar to how we handle block ciphers.  This is not a
big deal.

Really the only reason to even consider ahash at all would be try to support
software hashing and off-CPU hardware accelerators using the "same" code.
However, your proposal would not achieve that either, as it would not use the
async callback.  Note, as far as I know no one actually cares about off-CPU
hardware accelerator support in fsverity anyway...

The other thing is that verity doesn't benefit from shash at all.
It appears to be doing kmap's on every single request.

Cheers,
-- 
Email: Herbert Xu [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel