All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] random: use raw spinlocks for use on RT
Date: Mon, 1 Aug 2022 16:34:13 +0200	[thread overview]
Message-ID: <YufkZU9kGkHHUhAK@linutronix.de> (raw)
In-Reply-To: <20220801142530.133007-1-Jason@zx2c4.com>

On 2022-08-01 16:25:31 [+0200], Jason A. Donenfeld wrote:
> After handling several bug reports using various creative solutions,
> it's becoming clear that random bytes are actually a useful thing to
> happen from any ordinary context, including when interruptsare off.
> Actually, that's been long recognized, which is why the RNG uses
> spinlocks rather than mutexes. But on RT, those spinlocks are getting
> converted back into sleeping locks.
> 
> This clearly is causing more problems than it might hypothetically
> solve. Additionally, the locks in random.c are generally for fixed
> durations doing CPU-bound operations -- no waiting for hardware or I/O
> or the like. So this shouldn't result in a real harm to latency.
> 
> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> Sebastian - I won't move forward with this without your Ack, obviously.
> What do you think of this general approach? -Jason

I would need to do worst-case measurements and I've been looking at this
just before writting the other email and there was a local_lock_t
somewhere which needs also change…

So I have everything ready for 5.20 (6.0) ready without the RT patch and
then this vsprintf issues comes along…
From that point of view I would prefer to either init it upfront in a
way that works for everyone/ loose the first %p since it is probably a
minor inconvenience if nobody complains - instead swapping all locks.
We managed without this for kasan and lockdep which are both not used in
a production environment.

Sebastian

  reply	other threads:[~2022-08-01 14:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-01 14:25 [PATCH] random: use raw spinlocks for use on RT Jason A. Donenfeld
2022-08-01 14:34 ` Sebastian Andrzej Siewior [this message]
2022-08-01 14:41   ` Jason A. Donenfeld
2022-08-11  0:17   ` Jason A. Donenfeld
2022-08-11  7:15     ` Sebastian Andrzej Siewior
2022-08-11 14:20       ` Jason A. Donenfeld
2022-08-15 10:26         ` David Laight
2022-08-16 14:02         ` Jason A. Donenfeld
2022-08-29 19:45         ` Sebastian Andrzej Siewior
2022-08-29 19:56           ` Jason A. Donenfeld
2022-08-30 10:13             ` Sebastian Andrzej Siewior
2022-08-30 15:24               ` Jason A. Donenfeld
2022-08-30 18:57                 ` Sebastian Andrzej Siewior
2022-08-31 16:27                   ` Jason A. Donenfeld

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=YufkZU9kGkHHUhAK@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=Jason@zx2c4.com \
    --cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.