linux-kernel - Re: [PATCH v2 4/5] riscv: bitops: 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4dba27c4-e7a5-4ffc-8073-08a83c68e527@iscas.ac.cn>
Date: Fri, 22 Aug 2025 01:46:19 +0800
From: Vivian Wang <wangruikang@...as.ac.cn>
To: Yury Norov <yury.norov@...il.com>
Cc: Paul Walmsley <paul.walmsley@...ive.com>,
 Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
 Alexandre Ghiti <alex@...ti.fr>, Rasmus Villemoes
 <linux@...musvillemoes.dk>, 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,
 Vivian Wang <uwu@...m.page>
Subject: Re: [PATCH v2 4/5] riscv: bitops: Use __riscv_has_extension_likely

On 8/21/25 22:44, Yury Norov wrote:

> On Thu, Aug 21, 2025 at 05:16:34PM +0800, Vivian Wang wrote:
>> Use __riscv_has_extension_likely() to check for RISCV_ISA_EXT_ZBB,
>> replacing the use of asm goto with ALTERNATIVE.
>>
>> The "likely" variant is used to match the behavior of the original
>> implementation using ALTERNATIVE("j %l[legacy]", "nop", ...).
>>
>> Signed-off-by: Vivian Wang <wangruikang@...as.ac.cn>
>> ---
>>  arch/riscv/include/asm/bitops.h | 32 ++++++++------------------------
>>  1 file changed, 8 insertions(+), 24 deletions(-)
>>
>> diff --git a/arch/riscv/include/asm/bitops.h b/arch/riscv/include/asm/bitops.h
>> index d59310f74c2ba70caeb7b9b0e9221882117583f5..f70ccc0c2ffb86a6fda3bc373504143d0c6a1093 100644
>> --- a/arch/riscv/include/asm/bitops.h
>> +++ b/arch/riscv/include/asm/bitops.h
>> @@ -47,9 +47,8 @@
>>  
>>  static __always_inline unsigned long variable__ffs(unsigned long word)
>>  {
>> -	asm goto(ALTERNATIVE("j %l[legacy]", "nop", 0,
>> -				      RISCV_ISA_EXT_ZBB, 1)
>> -			  : : : : legacy);
>> +	if (!__riscv_has_extension_likely(0, RISCV_ISA_EXT_ZBB))
>> +		return generic___ffs(word);
> So, on the previous round you spent quite a lot of time explaining how
> 'unlikely()' version is handy over '!likely()', and now use just the
> latter. I feel really lost about how the code generation should look.

It's not "handy". The operative part is "has_extension", and both
functions return true if the extension is available and false if not.
Functionally:

    if (likely()) <-- equivalent --> if (unlikely())
    if (!likely()) <-- equivalent --> if (!unlikely())

Whereas:

    if (likely()) <-- **opposite of** --> if (!unlikely())
    if (unlikely()) <-- **opposite of** --> if (!likely())

All the asm goto dispatch stuff work like this:
static_branch_{likely,unlikely}, (arm64)
alternative_has_cap_{likely,unlikely},
__riscv_has_extension_{likely,unlikely}. Maybe it's confusing, but it
seems to be the convention.

And, codegen-wise:

ALTERNATIVE("j %l[no_alt]", "nop", ...) -> likely() ALTERNATIVE("nop",
"j %l[has_alt]", ...) -> unlikely()

Since the original code has the "likely" pattern, using "if (likely())"
preserves it. Whatever the codegen was, it's still the same.

> Can you please share bloat-o-meter report against this patch? Can you
> also show an example of code generation before and after? Have you
> tried the 'unlikely()` one? How the output looks?

Thanks for the tip on bloat-o-meter. I'll take a look tomorrow.

>>  	asm volatile (".option push\n"
>>  		      ".option arch,+zbb\n"
> Yeah, now the diff is much cleaner. Thanks.

This is why the condition at the top needed to be "!has_extension". So
the structure can be:

    if (!has_extension)
        return sw_version;

    multi_line
    zbb_version;

If I used "if (has_extension)" the code would need be

    if (has_extension) {
        multi_line
        zbb_version;
    } else {
        sw_version;
    }

And whether it was "likely" or "unlikely" had no bearing on the
structure of the code.

Vivian "dramforever" Wang