Subject: Re: cleanup the RAID5 XOR library v3

From: Eric Biggers <[email-masked]>
Date: Wed, 25 Mar 2026 12:39:54 -0700

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-masked], 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