linux-kernel - Re: [PATCH v3 0/5] riscv: Use __riscv_has_extension

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <60069cae-64fb-45de-8b74-e9a42a4b01b6@iscas.ac.cn>
Date: Sun, 12 Oct 2025 06:21:16 +0800
From: Vivian Wang <wangruikang@...as.ac.cn>
To: Conor Dooley <conor@...nel.org>
Cc: Paul Walmsley <paul.walmsley@...ive.com>,
 Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
 Alexandre Ghiti <alex@...ti.fr>, Yury Norov <yury.norov@...il.com>,
 Rasmus Villemoes <linux@...musvillemoes.dk>, Paul Walmsley <pjw@...nel.org>,
 Charlie Jenkins <charlie@...osinc.com>, Xiao Wang <xiao.w.wang@...el.com>,
 Christoph Müllner <christoph.muellner@...ll.eu>,
 linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/5] riscv: Use __riscv_has_extension_{likely,unlikely}


On 10/11/25 19:28, Conor Dooley wrote:
> On Sat, Oct 11, 2025 at 07:35:42AM +0800, Vivian Wang wrote:
>> There are about a dozen uses of asm goto in arch/riscv just to select
>> between two code paths with the alternative mechanism. Convert them to
>> the existing helpers __riscv_has_extension_{likely,unlikely}.
>>
>> In each case, I have preserved the existing code's choice of asm goto
>> pattern while picking between "likely" and "unlikely", namely:
>>
>>   ALTERNATIVE("j %l[no]", "nop", ...)   -> "likely"
>>   ALTERNATIVE("nop", "j %l[yes]", ...)  -> "unlikely"
>>
>> Since the helpers are just implementations of these patterns, the
>> performance should be the same as before.
> Can you explain why you're opting for the __ variant, instead of the one
> without __? They should do the same thing in your cases, and resolve to
> the alternative, since the non-alternative function call will be
> unreachable and the assert is compiletime. There's currently no users of
> the __ prefixed versions outside of other extension detection helpers, and
> I think it should probably be kept that way if possible.

I agree that it's preferable to use the non-__ functions. I'll do that
in the next version.

The only real reason I had used the __ versions is so that it would be
equivalent to existing code, although as you said these should be
equivalent since the uses are already guarded behind.

The "pgtable" code currently isn't guarded behind CONFIG_ALTERNATIVE,
although now that I think about it, it should actually be preferable to
do a runtime check than to do a TLB cleaning, so that one should
probably be non-__ as well.

Thanks,
Vivian "dramforever" Wang