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

[Eric Biggers <ebiggers@kernel.org>]

On Tue, Nov 10, 2026 at 11:52:03AM +1030, Qu Wenruo wrote:
> 在 2026/11/10 11:39, Eric Biggers 写道:
> > 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?
> 
> Indeed, it works almost flawlessly in user space just because there are
> already intrinsics available, and most of the code is just regular control
> flow, with mostly scalar code.
> 
> Thanks for the feedback, I'll just give up the idea in kernel, and enjoy the
> complete intrinsics in user space for now.
> 
> Thanks,
> Qu

Okay.  I'd be interested in someone trying to get the x86 intrinsics
working in the kernel, though.  Just when I last tried it, it still
wasn't possible to include <immintrin.h> without errors.

- Eric