linux-hardening - Re: [PATCH v3 2/3] prandom: Convert prandom_u32_state() to __always

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: <20260102225403.78e26214@pumpkin>
Date: Fri, 2 Jan 2026 22:54:03 +0000
From: David Laight <david.laight.linux@...il.com>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: Ryan Roberts <ryan.roberts@....com>, Catalin Marinas
 <catalin.marinas@....com>, Will Deacon <will@...nel.org>, Huacai Chen
 <chenhuacai@...nel.org>, Madhavan Srinivasan <maddy@...ux.ibm.com>, Michael
 Ellerman <mpe@...erman.id.au>, Paul Walmsley <pjw@...nel.org>, Palmer
 Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>, Heiko
 Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>, Alexander
 Gordeev <agordeev@...ux.ibm.com>, Thomas Gleixner <tglx@...utronix.de>,
 Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Dave Hansen
 <dave.hansen@...ux.intel.com>, Kees Cook <kees@...nel.org>, "Gustavo A. R.
 Silva" <gustavoars@...nel.org>, Arnd Bergmann <arnd@...db.de>, Mark Rutland
 <mark.rutland@....com>, Ard Biesheuvel <ardb@...nel.org>, Jeremy Linton
 <jeremy.linton@....com>, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, loongarch@...ts.linux.dev,
 linuxppc-dev@...ts.ozlabs.org, linux-riscv@...ts.infradead.org,
 linux-s390@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH v3 2/3] prandom: Convert prandom_u32_state() to
 __always_inline

On Fri, 2 Jan 2026 14:39:21 +0100
"Jason A. Donenfeld" <Jason@...c4.com> wrote:

> Hi Ryan,
...
> > +static __always_inline u32 prandom_u32_state(struct rnd_state *state)  
> 
> Why not just normal `inline`? Is gcc disagreeing with the inlinability
> of this function?

gcc has a mind of its own when it comes to inlining.
If there weren't some massive functions marked 'inline' that should never
really be inlined then making 'inline' '__always_inline' would make sense.
But first an audit would be needed.
(This has come up several times in the past.)
But if you need a function to be inlined (for any reason) it needs to be
always_inline.

Whether there should be an non-inlined 'option' here is another matter.
There could be a normal function that calls the inlined version.

	David

> 
> Jason
>