On Tue, Oct 31, 2023 at 10:48:56PM -0700, Eric Biggers wrote:
>
> Note that dm-verity also has to use an ugly and error-prone workaround to use
> ahash at all, since its hash blocks can be cached in vmalloc memory; see
> verity_hash_update().  shash handles vmalloc memory much more naturally, since
> no translation from vmalloc address to page to linear address is needed.

So why not drop ahash and always use shash? Does anybody care about
offload for dm-verity?

Alternatively, we could incorporate this into ahash itself.  Then
you could have an optimised code path that does not do SGs if the
underlying algorithm is shash.

I really do not wish to see this ahash/shash paradigm proliferate.

> > On a side note, if we're going to use shash for bulk data then we
> > should reintroduce the can/cannot sleep flag.
> 
> This patch limits the use of shash to blocks of at most PAGE_SIZE (*), which 
> is
> the same as what ahash does internally.
> 
> (*) Except when the data block size is <= PAGE_SIZE but the hash block size is
>     > PAGE_SIZE.  I think that's an uncommon configuration that's not worth
>     worrying too much about, but it could be excluded from the shash-based 
> code.

OK.  But we do still have the module signature verification code
path and I think that one still needs the can-sleep flag.

Thanks,
-- 
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Reply via email to