On Tue, Mar 25, 2025 at 01:53:28PM +0800, Herbert Xu wrote: > > crypto: hash - Add request chaining API Herbert didn't mention that I have nacked this patch, which he is insisting on pushing for some reason instead of my original version that is much better. Let me reiterate why "request chaining" is a bad idea and is going to cause problems. It makes it so that now a single hash request can now actually be a list of hash requests. It makes some of the crypto code operate on the whole list. However, most code still operates only on the first request in the list. It's undocumented and inconsistent which code is doing which, which is going to cause bugs. The first request in the list is also being treated specially in undocumented ways, so submitting a list of requests is not necessarily equivalent to submitting them all individually. Another recipe for bugs. Each hash request can also contain an entire scatterlist. It's overkill for what is actually needed for multibuffer hashing, which is a simple API that hashes two buffers specified by virtual address. Herbert's API creates lots of unnecessary edge cases, most of which lack any testing. It continues many of the worst practices of the crypto API that we *know* are not working, like requiring per-request memory allocations and optimizing for legacy hardware offload rather than the CPU-based crypto that almost everyone actually uses. In contrast, my patchset https://lore.kernel.org/r/20250212154718.44255-1-ebiggers@xxxxxxxxxx/ supports multibuffer hashing in a much better way and has been ready for a year already. It actually works; it has a smaller diffstat; it is faster; it has a much simpler API; and it actually includes all needed pieces including x86 and arm64 support, dm-verity and fs-verity support, and full documentation and tests. I've been spending a lot of time fixing the kernel's crypto code over the years. I'm not looking forward to having another set of major issues to fix. And this latest set of issues will be totally unnecessary. We can do better than this, especially for cryptography code. Nacked-by: Eric Biggers <ebiggers@xxxxxxxxxx> - Eric
