linux-kernel - Re: [PATCH 1/3] Compiler Attributes: Add _

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20250912102554.10147Bf8-hca@linux.ibm.com>
Date: Fri, 12 Sep 2025 12:25:54 +0200
From: Heiko Carstens <hca@...ux.ibm.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Nathan Chancellor <nathan@...nel.org>, Miguel Ojeda <ojeda@...nel.org>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Juergen Christ <jchrist@...ux.ibm.com>, linux-kernel@...r.kernel.org,
        linux-s390@...r.kernel.org, Sven Schnelle <svens@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>
Subject: Re: [PATCH 1/3] Compiler Attributes: Add __assume macro

On Thu, Sep 11, 2025 at 08:59:29PM +0200, Miguel Ojeda wrote:
> On Wed, Sep 10, 2025 at 5:12 PM Heiko Carstens <hca@...ux.ibm.com> wrote:
> >
> > + * Beware: Code which makes use of __assume must be written as if the compiler
> > + * ignores the hint. Otherwise this may lead to subtle bugs if code is compiled
> > + * with compilers which do not support the attribute.
> 
> I am not sure I understand this "Beware:" comment: is it referring to
> evaluation side-effects? If so, the GCC docs say it is not evaluated.
> The real danger is triggering UB with it, but that is different, i.e.
> one needs to be really, really sure the expression is true.

No, I was referring to the original build error where the missing "& 127" lead
to a warning / build error. So what I was trying to say: if you have a
construct like:

	...
	return a & 127;

and then make this:

	...
	__assume(a < 64);
	return a & 127;

then it is not possible to leave the "& 127" part away, since __assume() is
optional. But thinking about this again, I guess the comment is misleading,
like also your reply proved.

This is not about subtle bugs, but just an optimization that is not being
done, which may or may not lead to compile time warnings for the particular
case I was trying to improve; but the code would be correct in any case, as
long as __assume() is used correctly.

I'll rephrase the comment, and split / reorder patches differently so it is
(hopefully) more obvious what I try to achieve: allow for micro-optimizations
of inline assembly outputs.