mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ron Economos <re@w6rz.net>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>, linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org, Jon Hunter <jonathanh@nvidia.com>
Subject: Re: [PATCH] random: quiet urandom warning ratelimit suppression message
Date: Thu, 16 Jun 2022 19:10:36 -0700	[thread overview]
Message-ID: <f4dc15ff-10cf-bb73-5f72-874dd2b85f1a@w6rz.net> (raw)
In-Reply-To: <20220616132029.443033-1-Jason@zx2c4.com>

On 6/16/22 6:20 AM, Jason A. Donenfeld wrote:
> random.c ratelimits how much it warns about uninitialized urandom reads
> using __ratelimit. When the RNG is finally initialized, it prints the
> number of missed messages due to ratelimiting.
>
> It has been this way since that functionality was introduced back in
> 2018. Recently, cc1e127bfa95 ("random: remove ratelimiting for in-kernel
> unseeded randomness") put a bit more stress on the urandom ratelimiting,
> which teased out a bug in the implementation.
>
> Specifically, when under pressure, __ratelimit() will print its own
> message and reset the count back to 0, making the final message at the
> end less useful. Secondly, it does so as a pr_warn(), which apparently
> is undesirable for people's CI.
>
> Fortunately, __ratelimit() has the RATELIMIT_MSG_ON_RELEASE flag exactly
> for this purpose, so we set the flag.
>
> Fixes: 4e00b339e264 ("random: rate limit unseeded randomness warnings")
> Cc: stable@vger.kernel.org
> Reported-by: Jon Hunter <jonathanh@nvidia.com>
> Reported-by: Ron Economos <re@w6rz.net>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
>   drivers/char/random.c           |  2 +-
>   include/linux/ratelimit_types.h | 12 ++++++++----
>   2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index d0e4c89c4fcb..07a022e24057 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -87,7 +87,7 @@ static struct fasync_struct *fasync;
>   
>   /* Control how we warn userspace. */
>   static struct ratelimit_state urandom_warning =
> -	RATELIMIT_STATE_INIT("warn_urandom_randomness", HZ, 3);
> +	RATELIMIT_STATE_INIT_FLAGS("urandom_warning", HZ, 3, RATELIMIT_MSG_ON_RELEASE);
>   static int ratelimit_disable __read_mostly =
>   	IS_ENABLED(CONFIG_WARN_ALL_UNSEEDED_RANDOM);
>   module_param_named(ratelimit_disable, ratelimit_disable, int, 0644);
> diff --git a/include/linux/ratelimit_types.h b/include/linux/ratelimit_types.h
> index c21c7f8103e2..002266693e50 100644
> --- a/include/linux/ratelimit_types.h
> +++ b/include/linux/ratelimit_types.h
> @@ -23,12 +23,16 @@ struct ratelimit_state {
>   	unsigned long	flags;
>   };
>   
> -#define RATELIMIT_STATE_INIT(name, interval_init, burst_init) {		\
> -		.lock		= __RAW_SPIN_LOCK_UNLOCKED(name.lock),	\
> -		.interval	= interval_init,			\
> -		.burst		= burst_init,				\
> +#define RATELIMIT_STATE_INIT_FLAGS(name, interval_init, burst_init, flags_init) { \
> +		.lock		= __RAW_SPIN_LOCK_UNLOCKED(name.lock),		  \
> +		.interval	= interval_init,				  \
> +		.burst		= burst_init,					  \
> +		.flags		= flags_init,					  \
>   	}
>   
> +#define RATELIMIT_STATE_INIT(name, interval_init, burst_init) \
> +	RATELIMIT_STATE_INIT_FLAGS(name, interval_init, burst_init, 0)
> +
>   #define RATELIMIT_STATE_INIT_DISABLED					\
>   	RATELIMIT_STATE_INIT(ratelimit_state, 0, DEFAULT_RATELIMIT_BURST)
>   

Tested on 5.15.48 kernel for RISC-V RV64. Works good, urandom_read_iter 
warnings are suppressed.

Tested-by: Ron Economos <re@w6rz.net>


  reply	other threads:[~2022-06-17  2:10 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-14 18:40 [PATCH 5.10 00/11] 5.10.123-rc1 review Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 5.10 01/11] Documentation: Add documentation for Processor MMIO Stale Data Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 5.10 02/11] x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 5.10 03/11] x86/speculation: Add a common function for MD_CLEAR mitigation update Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 5.10 04/11] x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 5.10 05/11] x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 5.10 06/11] x86/speculation/mmio: Enable CPU Fill buffer clearing on idle Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 5.10 07/11] x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 5.10 08/11] x86/speculation/srbds: Update SRBDS mitigation selection Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 5.10 09/11] x86/speculation/mmio: Reuse SRBDS mitigation for SBDS Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 5.10 10/11] KVM: x86/speculation: Disable Fill buffer clear within guests Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 5.10 11/11] x86/speculation/mmio: Print SMT warning Greg Kroah-Hartman
2022-06-14 21:46 ` [PATCH 5.10 00/11] 5.10.123-rc1 review Florian Fainelli
2022-06-15  2:46 ` Shuah Khan
2022-06-15  5:00 ` Fox Chen
2022-06-15  9:20 ` Sudip Mukherjee
2022-06-15 17:57 ` Naresh Kamboju
2022-06-15 22:03 ` Guenter Roeck
2022-06-16  1:56 ` Samuel Zou
2022-06-16  3:28 ` Tyler Hicks
2022-06-16  8:48 ` Jon Hunter
2022-06-16  9:46   ` Ron Economos
2022-06-16 10:11     ` Jon Hunter
2022-06-16 13:16       ` Jason A. Donenfeld
2022-06-16 13:11   ` Jason A. Donenfeld
2022-06-16 13:17     ` Jon Hunter
2022-06-16 13:20       ` [PATCH] random: quiet urandom warning ratelimit suppression message Jason A. Donenfeld
2022-06-17  2:10         ` Ron Economos [this message]
2022-06-16 11:08 ` [PATCH 5.10 00/11] 5.10.123-rc1 review Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f4dc15ff-10cf-bb73-5f72-874dd2b85f1a@w6rz.net \
    --to=re@w6rz.net \
    --cc=Jason@zx2c4.com \
    --cc=jonathanh@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®