DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 36A29606A31C
Message-ID: <1f37e2df-a832-4184-b9fc-798f8325731e@suse.com>
Date: Tue, 10 Nov 2026 16:53:12 +1030
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] lib/crc: x86: rewrite crc32c_x86_3way() in C with inline
 asm
To: Qu Wenruo <quwenruo.btrfs@gmx.com>, Eric Biggers <ebiggers@kernel.org>
Cc: linux-btrfs@vger.kernel.org, linux-crypto@vger.kernel.org, ardb@kernel.org
References: <090c5f6603b1102c877c8649f7a6569f362bfe61.1794268279.git.wqu@suse.com>
 <20261110002255.GA1958@quark> <20261110010943.GB1958@quark>
 <44965cd2-30f9-4846-86b5-537f94f18958@suse.com> <20261110013546.GC1958@quark>
 <e2a8d755-c989-42bf-9adb-bb0ef2bc3872@gmx.com>
Content-Language: en-US
From: Qu Wenruo <wqu@suse.com>
Autocrypt: addr=wqu@suse.com; keydata=
 xsBNBFnVga8BCACyhFP3ExcTIuB73jDIBA/vSoYcTyysFQzPvez64TUSCv1SgXEByR7fju3o
 8RfaWuHCnkkea5luuTZMqfgTXrun2dqNVYDNOV6RIVrc4YuG20yhC1epnV55fJCThqij0MRL
 1NxPKXIlEdHvN0Kov3CtWA+R1iNN0RCeVun7rmOrrjBK573aWC5sgP7YsBOLK79H3tmUtz6b
 9Imuj0ZyEsa76Xg9PX9Hn2myKj1hfWGS+5og9Va4hrwQC8ipjXik6NKR5GDV+hOZkktU81G5
 gkQtGB9jOAYRs86QG/b7PtIlbd3+pppT0gaS+wvwMs8cuNG+Pu6KO1oC4jgdseFLu7NpABEB
 AAHNGFF1IFdlbnJ1byA8d3F1QHN1c2UuY29tPsLAlAQTAQgAPgIbAwULCQgHAgYVCAkKCwIE
 FgIDAQIeAQIXgBYhBC3fcuWlpVuonapC4cI9kfOhJf6oBQJq3ujyBQkUpLw5AAoJEMI9kfOh
 Jf6o8OIH/0mqW+TQM4m2x3hCsnK+oB4yJH1qnGvIhFF/Lhs48wI02sGh6/4aA0hkCDfd9LHQ
 +ci4FUepZ9y4VS01+oIExbg/8ytzGYTzLtb44jK2GBOBVSJkMiha6jp22XFt7WUkT/tvbreu
 WWdGsaJIRQaZChy7xsMI8lqQ2WdmluZJ4LT0wD3l/l6QU1ZseMGySebdY9sVOQEOJNV7Qj92
 /KOAFNmeZshV/qDI8Iw1RTs6TvLqCcqmlZLCmJkYSVhT1RonWRren8xIRcFEgMe004IDnt7V
 qdQhk/nhTS9x9MBAhMRl0TTE1VKDLvVALsud3iZLrmmtYvwPApzGJk052f0m28vOwE0EWdWB
 rwEIAKpT62HgSzL9zwGe+WIUCMB+nOEjXAfvoUPUwk+YCEDcOdfkkM5FyBoJs8TCEuPXGXBO
 Cl5P5B8OYYnkHkGWutAVlUTV8KESOIm/KJIA7jJA+Ss9VhMjtePfgWexw+P8itFRSRrrwyUf
 E+0WcAevblUi45LjWWZgpg3A80tHP0iToOZ5MbdYk7YFBE29cDSleskfV80ZKxFv6koQocq0
 vXzTfHvXNDELAuH7Ms/WJcdUzmPyBf3Oq6mKBBH8J6XZc9LjjNZwNbyvsHSrV5bgmu/THX2n
 g/3be+iqf6OggCiy3I1NSMJ5KtR0q2H2Nx2Vqb1fYPOID8McMV9Ll6rh8S8AEQEAAcLAfAQY
 AQgAJgIbDBYhBC3fcuWlpVuonapC4cI9kfOhJf6oBQJq3ukKBQkUzDspAAoJEMI9kfOhJf6o
 SNsH/1ysUWOKmzY0rGS3ZdS61QgqMGhSWD/EJ4UiPw+xO4l4+GtX0fOAqxqsmBKqje3vyhBa
 Z5o/1Y+gNiN+E6RBcSz4b1TAd78sQ2bvT5DWOvBjeeVxHdiuQMIn4S8xk5ZpySBw5ifjoiuL
 0M33UVtJOzM8yfAeL+d/Rp4leJw72SutjkLyZTG/gJIp4pJGD/kFHn24OLL0IxEcO0gOekNZ
 os5e1R6jAJ2ILk7+MDnvU8wXHcCiVzuDhJLI1tih1uUIE50muHQJWbYuVBbdJeu8WlIDDssx
 UOCxLylNG3gDXV5MhLubPTOpp9OiFc/XC37nvkgEcrlmlOFBv4/NJCbECpo=
In-Reply-To: <e2a8d755-c989-42bf-9adb-bb0ef2bc3872@gmx.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


在 2026/11/10 15:08, Qu Wenruo 写道:
> 
> 
> 在 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.

It looks like there is already 
`arch/arm64/include/asm/neon-intrinsics.h` including the intrinsics from 
the compiler and solves the conflicts manually.

So that looks like a solution to pull in the needed intrinsics to make 
things a little simpler.

> 
> Thanks,
> Qu
> 
>>
>> - Eric
>