Re: cleanup the RAID5 XOR library v3

Eric Biggers <[email protected]>
Newsgroups gmane.linux.ports.ppc64.devel,gmane.linux.ports.alpha,gmane.linux.kernel,gmane.linux.ports.arm.kernel,gmane.linux.ports.riscv,gmane.linux.ports.sparc,gmane.linux.uml.devel,gmane.linux.kernel.cryptoapi,gmane.comp.file-systems.btrfs,gmane.linux.kernel.cross-arch,gmane.linux.raid
Message-ID <20260325193954.GC2305@quark>
On Tue, Mar 24, 2026 at 07:21:36AM +0100, 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

This generally looks good, but yes, please check the comments from
https://sashiko.dev/#/patchset/[email protected], as
Andrew mentioned.

The bug where the test generates length 0 is definitely real.  I
verified it causes the test to crash on some platforms.

raid_run_ops() calling xor_gen() (indirectly) with preemption disabled
looks real as well, though I haven't tested it.  If preemption is indeed
not the right thing to check, then I guess (following up from
https://lore.kernel.org/linux-crypto/20260303195517.GC2846@sol/) it
would need to be something like:

    WARN_ON_ONCE(!in_task() || irqs_disabled() || softirq_count() != 0);

Ugly, but we're running out of options.

(This sort of thing is why the functions in lib/crypto/ and lib/crc/ are
just supported in all contexts instead.  If FPU/vector/SIMD registers
cannot be used in the current context, then a scalar fallback is used.)

- Eric
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.