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 62CA3E6BF1E for ; Fri, 30 Jan 2026 16:16:48 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [127.0.0.1]) by lists.ozlabs.org (Postfix) with ESMTP id 4f2h3L6rxHz2xT4; Sat, 31 Jan 2026 03:16:46 +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=1769789806; cv=none; b=NU6JGv2Z/6cD+o2SGWJkqLwSSvf+RqmGojM0KO+iEyi6t3Ms3i01InW/iaD7JFeSVtfxpQXcEIs4nyVNI92oEJ5vSk8UY9fPd3nLJoT2BJlzIBgg9elFscTC/Ld09Y/60Zt4p4ZLz2LJUke26d80xafdnnurOKFul7j5nZeiwWBie129wpUYUeTUrIO9BpNo57Se9pjiJfc7XoWrl6S0UlytLQSAwARN4vyG7hxBICWT5txFs5Atq+OoCv2H/C4DDFIkLdMr7hfDyS2+4KQQGzSDTdX5Q64K4LvqSwg2r/0C+nF+mwMknWM/0hqa8QJfcUvVdr8GUGwlMwzfQ+FwEQ== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1769789806; c=relaxed/relaxed; bh=9R2B8FSLGFMC0OlwEN1WnPoEMECK3FEtwbgv3hWtqSY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=R6fHVcO3c2Cr11HCNXv8uq8bhboqmJa2AqBsjnITs3zoo4yv0NuTXiC1FoBUlHMX0MVby65KYzTuoGYCUq7OL4DWYMcMwZkfdJM1QQhrcDIVRDnfbN/ZJe/VD33p+/r85vZ+2hih8GjQcHT7SQsqAhcC6m15yD7UI5EU5TNA1QMF/vy5FbVUJnuz1d9ZJ00NyIUSnjmlRoJgxLnGdM48a7ALPVOJnWODVtuVfQcfKrA7YlURK2mIbv0Kz+gaN6d/+s11FXJtNvf2ybxDTzFH8xs7DBQggN46UV7mUu5Rn/yE+qp+ChWLDYHTUYOaROjDzluqQVWLq0DL4Yi2JnKAmA== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=hOS7PmZZ; dkim-atps=neutral; spf=pass (client-ip=2600:3c0a:e001:78e:0:1991:8:25; helo=sea.source.kernel.org; envelope-from=chleroy@kernel.org; receiver=lists.ozlabs.org) smtp.mailfrom=kernel.org Authentication-Results: lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=hOS7PmZZ; 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=chleroy@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 4f2h3K3TNyz2xPW for ; Sat, 31 Jan 2026 03:16:45 +1100 (AEDT) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id BBCD143965; Fri, 30 Jan 2026 16:16:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5D006C4CEF7; Fri, 30 Jan 2026 16:16:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769789802; bh=AlNS0o8O55cP7ZrafFrQalBO7KdanY5615Qax8Ig75c=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=hOS7PmZZrFc5HSN1dVXhZyg9M/cciPSolaQqfWhYDg7HfF1XDoB1HNjJxeiK86UnM t0paeaoxtYjhwYcMLP8ehpw722gawXSmnt1Ff80sY7yEF5L7T7o1KVKgfa1P6xx/Uk S7DHHq636jQuWcXVs9rBcbEQ2QAQvrKFpcJM6bhZnxkVAsJwslEvfWUX4cXWiSjnms hkZcBfTLn6d4cw+9OyK7Jpzkky0ySo8aVXdV/3Vs41kEzOIubFCXlw7rvKNAruk9J0 NRQPKWhrHubAf3UrGWI3BkY7UvozmV6Ss4pPyWqiFlF2wY0RZojtLxb1ipESYS24SU AnDTT8wKSbTgQ== Message-ID: <993fb876-7958-4f1d-ba69-2601976a42d7@kernel.org> Date: Fri, 30 Jan 2026 17:16:32 +0100 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 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/3] prandom: Add __always_inline version of prandom_u32_state() To: "Jason A. Donenfeld" , 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 References: <20260119130122.1283821-1-ryan.roberts@arm.com> <20260119130122.1283821-3-ryan.roberts@arm.com> Content-Language: fr-FR From: "Christophe Leroy (CS GROUP)" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 28/01/2026 à 18:00, Jason A. Donenfeld a écrit : > 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. I looked into kernel sources and there are several functions named something_something_else_inline() and it doesn't mean those functions get inlined, so I would also prefer __prandom_u32_state() which means "If you use it you know what you are doing", just like __get_user() for instance. However maybe we could also reconsider making it inline for everyone. We have spotted half a dozen of places where the code size increases a lot when forcing it inline, but those places deserve a local trampoline to avoid code duplication, and then the compiler decides to inline or not. Because there are also several places that benefit from the inlining because it allows GCC to simplify the calculation, for instance when some calculation is performed with the result like with (prandom_u32_state(rng) % ceil) where ceil is 2 or 4. That can of course be done as a followup patch but it means at the end we will have to rename all __prandom_u32_state() to prandom_u32_state(). Or should we do the other way round ? Make __prandom_u32_state() the out-of-line version and just change the few places where the size explodes like drm_test_buddy_alloc_range_bias(), loss_gilb_ell(), generate_random_testvec_config(), generate_random_sgl_divisions(), mutate_buffer(), ... ? Christophe