linux-kernel - Re: [PATCH 1/6] riscv: Introduce use_alternative

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: <aKXtBJ5Aqqmvdc1B@yury>
Date: Wed, 20 Aug 2025 11:43:00 -0400
From: Yury Norov <yury.norov@...il.com>
To: Vivian Wang <wangruikang@...as.ac.cn>
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>,
	Vivian Wang <uwu@...m.page>, linux-riscv@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	Aydın Mercan <aydin@...can.dev>
Subject: Re: [PATCH 1/6] riscv: Introduce use_alternative_{likely,unlikely}

> > This 'unlikely' version is just an negation of 'likely' one, and it
> > looks like an attempt to save on one negation. On the other hand, the
> > function is __always_inline, which means that compiler should normally
> > take care of it. Can you prove with objdump that it really works as
> > intended? I mean that 
> >
> >         if (use_alternative_unlikely())
> >                 do_something();
> >
> > generates a better code than 
> >         
> >         if (!use_alternative_likely())
> >                 do_something();
> 
> use_alternative_likely() and use_alternative_unlikely() are not
> negations of each other and in fact should be functionally equivalent. I
> also briefly explained the difference in the comment, but the difference
> is which case is nop i.e. fallthrough, and which case requires a jump
> instruction. The likely case should get a "nop", and the unlikely case
> should get a "j %l[...]". This choice does work as intended [1].
> 
> I don't think it is possible to give both options to the compiler, so at
> least for now AIUI users have to pick one.
> 
> The same applies to __riscv_has_extension_{likely,unlikely}.
> 
> Vivian "dramforever" Wang
> 
> [1]: https://godbolt.org/z/v8zTEhzTx

I realize that likely and unlikely versions generate different code,
I'm just not convinced that

1. it works in real kernel as intended, not only in the godbold; and
2. has any measurable impact.

That's why I asked you to share objdump and possibly perf tests.