On Mon, Aug 11, 2025 at 10:10:44AM +0300, Linus Torvalds wrote:
> On Mon, 11 Aug 2025 at 07:44, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> 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
