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

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

在 2026/11/10 12:05, Eric Biggers 写道:
> 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.

I don't think we can use the compiler's wrappers directly, there are 
quite a lot of conflicts with kernel's library.

So a different, independent copy may be needed.

If we can get that part done, it will be much easier to do the conversion.
Although introducing the intrinsics itself may be a much larger project.

Thanks,
Qu

> 
> - Eric