Re: [PATCH] lib/crc: x86: rewrite crc32c_x86_3way() in C with inline asm

[Eric Biggers <ebiggers@kernel.org>]

On Mon, Nov 09, 2026 at 04:22:55PM -0800, Eric Biggers wrote:
> As much as I'd like to reduce the use of asm, I'm not sure this is super
> convincing.  We get worse code generation and have to fall back to
> inline asm anyway, as the x86 intrinsics are still unusable in the
> kernel (which is different from userspace).
> 
> This patch also introduces a compiler error with gcc. It seems only
> clang was tested.  (Showing again that this kind of code often has
> compiler-specific issues, and we have to be extra careful to test it
> with every supported compiler version.)
> 
> There's also a subtle bug where the inline asm blocks are missing the
> volatile qualifier, so technically they could be reordered after the
> kernel_fpu_end() and corrupt a userspace process's XMM registers.
> Without inline asm, this issue would not have been possible.
> 
> I'd be interested in seeing what you can come up with for
> crc-pclmul-template.S, though I think that one is going to be harder to
> replace.

Also, just to emphasize: most "C" code using this strategy will be
mostly inline asm blocks, since that's what is needed to access the
vector registers in kernel code.  See lib/raid/*/x86/ for some examples.

crc32c_x86_3way() is an exception because it mostly use scalar
instructions, with only a few vector instructions.  So it makes this
strategy seem a bit more workable.  But actually, as soon as this same
strategy is adopted for crc-pclmul-template.S or any of the many crypto
assembly files (AES, GHASH, ChaCha, Poly1305, BLAKE2, etc.) that use far
more vector instructions, it will become mostly inline asm blocks, just
like the RAID code.

So I feel it's kind of an odd path to go down.  Perhaps as a
prerequisite for reimplementing some of this code in C (or will it soon
be Rust?), we should get the x86 intrinsics working in the kernel first?

- Eric