DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 82DA660A2620
Message-ID: <44965cd2-30f9-4846-86b5-537f94f18958@suse.com>
Date: Tue, 10 Nov 2026 11:52:03 +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: 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>
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: <20261110010943.GB1958@quark>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


在 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

> 
> - Eric