linux-kernel - Re: [PATCH] random: remove mostly unused async readiness notifier

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YoNvb265RG5pOObU@zx2c4.com>
Date:   Tue, 17 May 2022 11:48:31 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Petr Mladek <pmladek@...e.com>
Cc:     linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
        Steven Rostedt <rostedt@...dmis.org>,
        Sergey Senozhatsky <senozhatsky@...omium.org>
Subject: Re: [PATCH] random: remove mostly unused async readiness notifier

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@...e.com>

Okay, I'll do this. And then let's circle around the memory barriers
whenever you feel like it later.

Jason