Re: [PATCH] crypto: hash - Make HASH_MAX_DESCSIZE a bit more obvious

[Eric Biggers <ebiggers@kernel.org>]

On Mon, Aug 11, 2025 at 10:10:44AM +0300, Linus Torvalds wrote:
> On Mon, 11 Aug 2025 at 07:44, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> >
> > The patch below should make the constant a bit more obvious.
> 
> Indeed.
> 
> It would be good to maybe minimize the on-stack max-sized allocations,
> but that's a separate issue. Several hundred bytes is a noticeable
> part of the stack, and it's not always clear that it's a shallow stack
> with not a lot else going on..
> 
> (I just randomly picked the btrfs csum hash to look at, which can
> apparently be one of crc32c / xxhash64 / sha256 or blake2b, and which
> is then used at bio submission time, and I wouldn't be surprised if it
> probably has a pretty deep stack at that point already).

HASH_MAX_DESCSIZE has to be enough for *any* algorithm accessible via
the crypto_shash API, which makes HMAC-SHA3-224 be the limiting factor.
By converting users to use the library APIs instead, they will instead
use strongly-typed contexts that are sized correctly for the algorithms
actually being used.  In the btrfs csum case, the applicable sizes are:

    shash_desc + HASH_MAX_DESCSIZE: 377
    blake2b: 232
    sha256: 104
    xxhash64: 76
    crc32c: 4

So the reduction for btrfs will be 377 => 232.  But blake2b is missing a
library API, so I need to add that first.

- Eric