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: <YoN88JdmiTO39nqk@alley>
Date:   Tue, 17 May 2022 12:46:08 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     "Jason A. Donenfeld" <Jason@...c4.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

On Tue 2022-05-17 11:48:31, Jason A. Donenfeld wrote:
> 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.

Fair enough.

> > 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.

OK, let's stick with your version in 5.19.

I will later send a patch with the barriers when time permits.
But it will probably be for the next release.

Best Regards,
Petr