Re: [PATCH 2/2] crypto/crc32[c]: register only "-lib" drivers

[Eric Biggers <ebiggers@kernel.org>]

On Tue, Jun 17, 2025 at 01:20:50PM -0700, Eric Biggers wrote:
> On Tue, Jun 17, 2025 at 10:17:48PM +0200, David Sterba wrote:
> > On Fri, Jun 13, 2025 at 11:37:53AM -0700, Eric Biggers wrote:
> > > From: Eric Biggers <ebiggers@google.com>
> > > 
> > > For the "crc32" and "crc32c" shash algorithms, instead of registering
> > > "*-generic" drivers as well as conditionally registering "*-$(ARCH)"
> > > drivers, instead just register "*-lib" drivers.  These just use the
> > > regular library functions crc32_le() and crc32c(), so they just do the
> > > right thing and are fully accelerated when supported by the CPU.
> > > 
> > > This eliminates the need for the CRC library to export crc32_le_base()
> > > and crc32c_base().  Separate patches make those static functions.
> > > 
> > > Since this patch removes the "crc32-generic" and "crc32c-generic" driver
> > > names which crypto/testmgr.c expects to exist, update crypto/testmgr.c
> > > accordingly.  This does mean that crypto/testmgr.c will no longer
> > > fuzz-test the "generic" implementation against the "arch" implementation
> > > for crc32 and crc32c, but this was redundant with crc_kunit anyway.
> > > 
> > > Besides the above, and btrfs_init_csum_hash() which the previous patch
> > > fixed, no code appears to have been relying on the "crc32-generic" or
> > > "crc32c-generic" driver names specifically.
> > > 
> > > btrfs does export the checksum driver name in
> > > /sys/fs/btrfs/$uuid/checksum.  This patch makes that file contain
> > > "crc32c-lib" instead of "crc32c-generic" or "crc32c-$(ARCH)".  This
> > > should be fine, since in practice the purpose of this file seems to have
> > > been just to allow users to manually check whether they needed to enable
> > > the optimized CRC32C code.  This was needed only because of the bug in
> > > old kernels where the optimized CRC32C code defaulted to off and even
> > > needed to be explicitly added to the ramdisk to be used.  Now that it
> > > just works in Linux 6.14 and later, there's no need for users to take
> > > any action and this file is basically obsolete.
> > 
> > Well, not the whole file, because it says which checksumming algo is
> > used for the filesystem, but the implementation part is.
> 
> Oh, right.  It's one of those sysfs files that don't follow the normal sysfs
> convention and contain multiple values.  I'll update the paragraph above to
> clarify that it's referring to the driver name part of the file.

I revised it to:

btrfs does export the checksum name and checksum driver name in
/sys/fs/btrfs/$uuid/checksum.  This commit makes the driver name portion
of that file contain "crc32c-lib" instead of "crc32c-generic" or
"crc32c-$(ARCH)".  This should be fine, since in practice the purpose of
the driver name portion of this file seems to have been just to allow
users to manually check whether they needed to enable the optimized
CRC32C code.  This was needed only because of the bug in old kernels
where the optimized CRC32C code defaulted to off and even needed to be
explicitly added to the ramdisk to be used.  Now that it just works in
Linux 6.14 and later, there's no need for users to take any action and
the driver name portion of this is basically obsolete.  (Also, note that
the crc32c driver name already changed in 6.14.)