From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 30AC8D3F097 for ; Wed, 28 Jan 2026 17:01:00 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [127.0.0.1]) by lists.ozlabs.org (Postfix) with ESMTP id 4f1T7G5FSxz2xlK; Thu, 29 Jan 2026 04:00:58 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; arc=none smtp.remote-ip="2600:3c0a:e001:78e:0:1991:8:25" ARC-Seal: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1769619658; cv=none; b=njHZTZZ3u1FgHbEaxo5356bNmsV+icEeCEkDhO77wSEsWLtxI/c19CvGP3TBk4lAW61Qs5id8YRoJb9fafM5EyWISLkaGBwEqgdCTsGWWBfa3WIoi4bhPdzb+Q2sYkzUDov8DZEOG0rcLmdUeAc6VziVpIHqSyiDwQH26T1tGdF3nx3vugMEcw5+CjrIL3PfVkpH2PcXUkQ7WqBKnM8x+3APWeCgZGwbUA6mHR9WSnl6/vvt6fYZ7CHLFSWUUJZoKhfEiNRfVKO8qxAh3KSvNmstddcPAPdp8C8Dv/ckU4/Bxt0eWnqhVWB7ECW1Hip6VUeqfHs6Jgp6tOIuEPCX9Q== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1769619658; c=relaxed/relaxed; bh=tn4g/9//RsuI8p+PfBKBMGxP/jMELrcAL7s9pAP33WA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LB0AaT7C1tOfFt1aKNYvuYAZgj+G/dlzoZQm1KKYOIw55SKqCWAI6dcCsRO6iPEYjOnMB/kJAW/VqPFgVFEk77QyXSg88cslIbGVSenpWrUHOrEFvpwFg5tU3yVn0Byk69obl6BDqYdscbGKEeBJR1QT4Mun4MGM5cxPwyLgZun0svPgrkHxixzupLFDbZMlyVj7Ne1Qaf75AQZofFeBzPKYYG3PQmchJiEJLrO9SdM3lyRqzWSUjwoJw7Ol1ELigTOnwUGXgFRlq2+oramR2Pgn0W2b9zs3eddiCbD/co30lRqVNwARryIfMBpvpGr0SR0jwKLMCrSni9oWCww4LQ== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=zx2c4.com; dkim=pass (1024-bit key; unprotected) header.d=zx2c4.com header.i=@zx2c4.com header.a=rsa-sha256 header.s=20210105 header.b=m2wKvC3q; dkim-atps=neutral; spf=pass (client-ip=2600:3c0a:e001:78e:0:1991:8:25; helo=sea.source.kernel.org; envelope-from=srs0=wv9x=ab=zx2c4.com=jason@kernel.org; receiver=lists.ozlabs.org) smtp.mailfrom=kernel.org Authentication-Results: lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=zx2c4.com Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=zx2c4.com header.i=@zx2c4.com header.a=rsa-sha256 header.s=20210105 header.b=m2wKvC3q; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=2600:3c0a:e001:78e:0:1991:8:25; helo=sea.source.kernel.org; envelope-from=srs0=wv9x=ab=zx2c4.com=jason@kernel.org; receiver=lists.ozlabs.org) Received: from sea.source.kernel.org (sea.source.kernel.org [IPv6:2600:3c0a:e001:78e:0:1991:8:25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4f1T7C6Rjlz2xgv for ; Thu, 29 Jan 2026 04:00:55 +1100 (AEDT) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id CA43D41B6E; Wed, 28 Jan 2026 17:00:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF87CC4CEF7; Wed, 28 Jan 2026 17:00:50 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="m2wKvC3q" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1769619644; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tn4g/9//RsuI8p+PfBKBMGxP/jMELrcAL7s9pAP33WA=; b=m2wKvC3qDETjKG8j143DAoxEEYCt8XypTTP1fkG55IkiGr/El87+qNAqFmJAhmO5Ss4QvO luTaIueGqjBBUWvKkPauPs45CQSo4/Z464etuqYdgloGfvYxQ/yKi612qCksjG3596dGqI ftt2n6cXvdkVFbr1KrLxJuY4x/ZjghA= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id bd2c9de1 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 28 Jan 2026 17:00:40 +0000 (UTC) Date: Wed, 28 Jan 2026 18:00:30 +0100 From: "Jason A. Donenfeld" To: Ryan Roberts Cc: Catalin Marinas , Will Deacon , Huacai Chen , Madhavan Srinivasan , Michael Ellerman , Paul Walmsley , Palmer Dabbelt , Albert Ou , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Kees Cook , "Gustavo A. R. Silva" , Arnd Bergmann , Mark Rutland , Ard Biesheuvel , Jeremy Linton , David Laight , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH v4 2/3] prandom: Add __always_inline version of prandom_u32_state() Message-ID: References: <20260119130122.1283821-1-ryan.roberts@arm.com> <20260119130122.1283821-3-ryan.roberts@arm.com> X-Mailing-List: linuxppc-dev@lists.ozlabs.org List-Id: List-Help: List-Owner: List-Post: List-Archive: , List-Subscribe: , , List-Unsubscribe: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260119130122.1283821-3-ryan.roberts@arm.com> 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 > Signed-off-by: Ryan Roberts > --- > 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. Jason