On 11/2/24 5:36 PM, Eric Biggers wrote:
On Sat, Nov 02, 2024 at 07:08:43PM +0800, Herbert Xu wrote:
On Sat, Nov 02, 2024 at 12:05:01PM +0100, Ard Biesheuvel wrote:
The only issue resulting from *not* taking this patch is that btrfs
may misidentify the CRC32 implementation as being 'slow' and take an
alternative code path, which does not necessarily result in worse
performance.
If we were removing crc32* (or at least crc32*-arch) from the Crypto
API then these patches would be redundant. But if we're keeping them
because btrfs uses them then we should definitely make crc32*-arch
do the right thing. IOW they should not be registered if they're
the same as crc32*-generic.
Thanks,
I would like to eventually remove crc32 and crc32c from the crypto API, but it
will take some time to get all the users converted. If there are AF_ALG users
it could even be impossible, though the usual culprit, iwd, doesn't appear to
use any CRCs, so hopefully we are fine there.
Hi,
Please do not forget about dm-integrity, it can use crc32/crc32c for non-cryptographic
integrity through crypto API.
To test it, cryptsetup testsuite should cover these variants (integrity-compat-test).
Also, libcryptsetup can be compiled with userspace kernel crypto (AF_ALG) as a crypto backend.
At least, I think we never used CRC32 though AF_ALG from userspace there...
Thanks,
Milan
