From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Petr Mladek <pmladek@suse.com>
Cc: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: Re: [PATCH] random: remove mostly unused async readiness notifier
Date: Tue, 17 May 2022 11:48:31 +0200 [thread overview]
Message-ID: <YoNvb265RG5pOObU@zx2c4.com> (raw)
In-Reply-To: <YoNlNs7vGcAy8rU3@alley>
Hi Petr,
On Tue, May 17, 2022 at 11:04:54AM +0200, Petr Mladek wrote:
> I would go even further. The workqueue is needed only because we are not
> able to switch the static branch in an atomic context.
>
> But the static branch looks like an over-optimization.
> vsprintf() is a slow path. It will be enough to use a normal
> variable.
>
> Well, it would be nice to check it without the spinlock to keep it
> fast and avoid problems with the spin lock during panic().
>
> What about?
That all makes sense to me, but I'm a bit worried about changing too
much from the original design in a commit mostly intended on removing
things from random.c. Maybe we can do the patch I sent here, and then
once that lands in 5.19, we can do some more simplifications as
standalone commits that you can assess. Or if you're adamant about doing
this now, maybe you can send a patch that I can apply on _top_ of this
commit here?
The reason I'm a bit cautious is because I recall the original code from
Tobin way back had some smp_wmb() just like this, but it got removed and
replaced with that static branch. So at least somebody felt differently
about it. Which means it'll probably be a whole discussion with more
people, and I'm probably not the right person to lead that.
> Well, your approach with static_key is fine as well. Feel free
> to use:
>
> Acked-by: Petr Mladek <pmladek@suse.com>
Okay, I'll do this. And then let's circle around the memory barriers
whenever you feel like it later.
Jason
next prev parent reply other threads:[~2022-05-17 9:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-14 11:23 [PATCH] random: remove get_random_bytes_arch() and add rng_has_arch_random() Jason A. Donenfeld
2022-05-15 13:18 ` Jason A. Donenfeld
2022-05-15 13:19 ` [PATCH] random: remove mostly unused async readiness notifier Jason A. Donenfeld
2022-05-17 9:04 ` Petr Mladek
2022-05-17 9:48 ` Jason A. Donenfeld [this message]
2022-05-17 10:46 ` Petr Mladek
2022-05-18 8:54 ` Petr Mladek
2022-05-18 9:52 ` Jason A. Donenfeld
2022-05-18 9:56 ` [PATCH v2] " Jason A. Donenfeld
2022-05-19 7:10 ` Petr Mladek
2022-05-17 7:54 ` [PATCH] random: remove get_random_bytes_arch() and add rng_has_arch_random() Petr Mladek
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=YoNvb265RG5pOObU@zx2c4.com \
--to=jason@zx2c4.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.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;
as well as URLs for NNTP newsgroup(s).