On Sat, Apr 12, 2025 at 06:57:17PM +0800, Herbert Xu wrote: > This series is based on > > https://lore.kernel.org/linux-crypto/cover.1744454589.git.herbert@xxxxxxxxxxxxxxxxxxx > > Add helpers to use stack requests with any ahash algorithm, with > optional dynamic allocation when required for async. > > THe rest of the series are miscellaneous fixes in preparation for > the next series which will introduce block-only shash. What is a "block-only shash" and why does it make sense? Based on the name, the fact that patch 8 is fiddling with cra_blocksize for one of the algorithms, and your general preference for trying to make the "Crypto API" solve problems even when it's not the right solution, I'm assuming that you're planning to make crypto/shash.c do the block buffering for all shash algorithms "automatically" using cra_blocksize. That doesn't actually make sense, though. The more logical way to organize the code, as I think my patchsets converting crc32, crc32c, and poly1305 make very clear, is to have the shash API be implemented using the library API. The library API has to handle arbitrary length inputs anyway, so it has to implement the block buffering anyway. Thus, there's no need for shash to do it at all. shash merely needs to know the block size and declare it in cra_blocksize for users who want it for some reason (e.g. for padding salts to the block size). shash should not care about the block size in any other way. It's true that e.g. in the case of poly1305, each arch's library code implements the block buffering. So the redundancy that I think you're trying to solve does exist in the library too. But, the solution to that is to move the block buffering up one level, to poly1305_update(), so that it's shared by all the arches, just like what blake2s already does. I am going to consider doing this, especially as I get around to fixing the other hash algorithms. (If we do this for Poly1305, it would be an additional cleanup on top of my patch series https://lore.kernel.org/linux-crypto/20250413045421.55100-1-ebiggers@xxxxxxxxxx/) But, this has nothing to do with shash; shash plays no role in the solution. - Eric
