On Wed, 28 Jan 2026 17:33:19 +0000 Ryan Roberts <[email protected]> wrote:
> 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). If you are going to respin: (e.g. noinst or performance critical code). David > >> + */ > >> +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 >
