Re: cleanup the RAID5 XOR library v4
"Ard Biesheuvel" <[email protected]>
| Newsgroups | gmane.linux.uml.devel,gmane.linux.ports.alpha,gmane.linux.kernel,gmane.linux.ports.arm.kernel,gmane.linux.ports.ppc64.devel,gmane.linux.ports.riscv,gmane.linux.ports.sparc,gmane.linux.kernel.cryptoapi,gmane.comp.file-systems.btrfs,gmane.linux.kernel.cross-arch,gmane.linux.raid |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 27 Mar 2026, at 07:16, Christoph Hellwig wrote: > Hi all, > > the XOR library used for the RAID5 parity is a bit of a mess right now. > The main file sits in crypto/ despite not being cryptography and not > using the crypto API, with the generic implementations sitting in > include/asm-generic and the arch implementations sitting in an asm/ > header in theory. The latter doesn't work for many cases, so > architectures often build the code directly into the core kernel, or > create another module for the architecture code. > > Changes this to a single module in lib/ that also contains the > architecture optimizations, similar to the library work Eric Biggers > has done for the CRC and crypto libraries later. After that it changes > to better calling conventions that allow for smarter architecture > implementations (although none is contained here yet), and uses > static_call to avoid indirection function call overhead. > > A git tree is also available here: > > git://git.infradead.org/users/hch/misc.git xor-improvements > > Gitweb: > > > https://git.infradead.org/?p=users/hch/misc.git;a=shortlog;h=refs/heads/xor-improvements > > Changes since v3: > - switch away from lockdep_assert_preemption_enabled() again > - fix a @ reference in a kerneldoc comment. > - build the arm4regs implementation also without kernel-mode neon > support > - fix a pre-existing issue about mismatched attributes on arm64's > xor_block_inner_neon > - reject 0-sized xor request and adjust the kunit test case to not > generate them > > Changes since v2: > - drop use of CONFIG_KERNEL_MODE_NEON for arm64 > - drop the new __limit_random_u32_below for the unit test > - require 64-bit alignment because sparc64 requires it > - use DEFINE_STATIC_CALL_NULL to avoid exposing a specific xor_gen > routine > - keep CONFIG_XOR_BLOCKS_ARCH self-contained in lib/raid/ > - don't select library option from kunit test and add a .kunitconfig > instead > - fix the module description for the kunit test > - add a case where buffers are at the end of the allocation in the kunit test > - use separate src/dst alignment in the kunit test > - fix and improve the kunit assert message > > Changes since v1: > - use lockdep_assert_preemption_enabled() > - improve the commit message for the initial um xor.h cleanup > - further clean up the um arch specific header > - add SPDX identifier to the new build system files > - use bool for xor_forced > - fix an incorrect printk level conversion from warn to info > - include xor_impl.h in xor-neon.c > - remove unused exports for riscv > - simply move the sparc code instead of splititng it > - simplify the makefile for the x86-specific implementations > - remove stray references to xor_blocks in crypto/async_tx > - rework __DO_XOR_BLOCKS to avoid (theoretical) out of bounds references > - improve the kerneldoc API documentration for xor_gen() > - spell the name of the srcs argument to xor_gen correctly in xor.h > - add a kunit test, and a new random helper for it. > For the series, Acked-by: Ard Biesheuvel <[email protected]> As discussed, arm64 and ARM can share the NEON intrinsics implementation, which would allow for a bit of cleanup as well. I'll follow up with some patches based on this series.