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 <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt