Re: [PATCH 10/10] btrfs: switch to library APIs for checksums

[Eric Biggers <ebiggers@kernel.org>]

On Wed, Oct 22, 2025 at 09:11:41AM +0200, David Sterba wrote:
> On Fri, Oct 17, 2025 at 09:31:06PM -0700, Eric Biggers wrote:
> > Make btrfs use the library APIs instead of crypto_shash, for all
> > checksum computations.  This has many benefits:
> > 
> > - Allows future checksum types, e.g. XXH3 or CRC64, to be more easily
> >   supported.  Only a library API will be needed, not crypto_shash too.
> > 
> > - Eliminates the overhead of the generic crypto layer, including an
> >   indirect call for every function call and other API overhead.  A
> >   microbenchmark of btrfs_check_read_bio() with crc32c checksums shows a
> >   speedup from 658 cycles to 608 cycles per 4096-byte block.
> > 
> > - Decreases the stack usage of btrfs by reducing the size of checksum
> >   contexts from 384 bytes to 240 bytes, and by eliminating the need for
> >   some functions to declare a checksum context at all.
> > 
> > - Increases reliability.  The library functions always succeed and
> >   return void.  In contrast, crypto_shash can fail and return errors.
> >   Also, the library functions are guaranteed to be available when btrfs
> >   is loaded; there's no longer any need to use module softdeps to try to
> >   work around the crypto modules sometimes not being loaded.
> > 
> > - Fixes a bug where blake2b checksums didn't work on kernels booted with
> >   fips=1.  Since btrfs checksums are for integrity only, it's fine for
> >   them to use non-FIPS-approved algorithms.
> > 
> > Note that with having to handle 4 algorithms instead of just 1-2, this
> > commit does result in a slightly positive diffstat.  That being said,
> > this wouldn't have been the case if btrfs had actually checked for
> > errors from crypto_shash, which technically it should have been doing.
> > 
> > Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> 
> Thanks, this simplifies quite a few things. I'd like to take it via the
> btrfs tree as there may be the hash additions (XXH3, BLAKE3) but
> currently I'm not sure if it won't make things more complicated. I
> haven't started the kernel part yet so I can use this patchset for
> development and rebase once it's merged. 

Great.  I'm planning to take patches 1-9 through libcrypto-next for
6.19.  You can then take patch 10 through the btrfs tree for 6.20.  Does
that sound good?  We can work out the XXH3 and BLAKE3 support later.  If
you'd like to add another checksum algorithm, I'd suggest picking just
one.  btrfs already supports an awful lot of choices for the checksum.
But we can discuss that later.

- Eric