On 28/01/2026 17:00, Jason A. Donenfeld wrote: > On Mon, Jan 19, 2026 at 01:01:09PM +0000, Ryan Roberts wrote: >> We will shortly use prandom_u32_state() to implement kstack offset >> randomization and some arches need to call it from non-instrumentable >> context. So let's implement prandom_u32_state() as an out-of-line >> wrapper around a new __always_inline prandom_u32_state_inline(). kstack >> offset randomization will use this new version. >> >> Acked-by: Mark Rutland <[email protected]> >> Signed-off-by: Ryan Roberts <[email protected]> >> --- >> include/linux/prandom.h | 20 ++++++++++++++++++++ >> lib/random32.c | 8 +------- >> 2 files changed, 21 insertions(+), 7 deletions(-) >> >> diff --git a/include/linux/prandom.h b/include/linux/prandom.h >> index ff7dcc3fa105..801188680a29 100644 >> --- a/include/linux/prandom.h >> +++ b/include/linux/prandom.h >> @@ -17,6 +17,26 @@ struct rnd_state { >> __u32 s1, s2, s3, s4; >> }; >> >> +/** >> + * prandom_u32_state_inline - seeded pseudo-random number generator. >> + * @state: pointer to state structure holding seeded state. >> + * >> + * This is used for pseudo-randomness with no outside seeding. >> + * For more random results, use get_random_u32(). >> + * For use only where the out-of-line version, prandom_u32_state(), cannot >> be >> + * used (e.g. noinstr code). >> + */ >> +static __always_inline u32 prandom_u32_state_inline(struct rnd_state *state) > > This is pretty bikesheddy and I'm not really entirely convinced that my > intuition is correct here, but I thought I should at least ask. Do you > think this would be better called __prandom_u32_state(), where the "__" > is kind of a, "don't use this directly unless you know what you're doing > because it's sort of internal"? It seems like either we make this inline > for everybody, or if there's a good reason for having most users use the > non-inline version, then we should be careful that new users don't use > the inline version. I was thinking the __ would help with that.
I'm certainly happy to do that, if that's your preference. I have to respin this anyway, given the noinstr issue. > > Jason
