On Fri, 18 Oct 2024 at 00:04, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > On Thu, Oct 17, 2024 at 06:30:19PM +0200, Ard Biesheuvel wrote: > > > Ard Biesheuvel (2): > > > arm64/lib: Handle CRC-32 alternative in C code > > > arm64/crc32: Implement 4-way interleave using PMULL > > > > > > > I'll need to respin this - the crc32_be code doesn't actually work correctly. > > Right, good catch. It looks like it needs an rbit of the crc value at the > beginning and end. lib/crc32test.c doesn't actually test crc32_be_arm64_4way() > because it runs the tests with IRQs disabled; it probably shouldn't do that. > Yeah, we should probably fix that. > On a slightly related topic, since any crc32_le() and __crc32c_le() functions in > arch/*/lib/ are automatically exposed as shash algorithms via the crypto API > (this was already the case, but your other patch makes this more explicit by > properly separating them from the generic implementation), I wonder if all the > remaining arch/*/crypto/crc32*.c should be migrated to arch/*/lib/, and then > users of crc32 and crc32c like ext4 and f2fs should just use the library > functions instead of shash. That would simply things greatly. See e.g. the > horrible hacks used in ext4_chksum() and __f2fs_crc32()... > > The only crc32 and crc32c implementations that *aren't* software based are those > in drivers/crypto/stm32/stm32-crc32.c and > drivers/crypto/inside-secure/safexcel_hash.c. Access to those would be lost by > going through lib. But I strongly suspect they exist just because the hardware > supported it and not because they are actually useful. > Indeed. Another case where the flexibility of the shash interface doesn't buy us anything but overhead and complexity.
