linux-kernel - Re: [PATCH] random: use raw spinlocks for use on RT

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: <YvSsf5uds7zGgWPX@linutronix.de>
Date:   Thu, 11 Aug 2022 09:15:11 +0200
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     linux-kernel@...r.kernel.org, tglx@...utronix.de
Subject: Re: [PATCH] random: use raw spinlocks for use on RT

On 2022-08-11 02:17:31 [+0200], Jason A. Donenfeld wrote:
> Hey Sebastian,
Hi Jason,

> > > 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…
> 
> Did you ever come up some measurements here? It sure would be nice if I
> could apply this, but obviously that's contingent on you saying it's
> okay latency-wise on RT.

No, I did not. But I've been thinking a little about it. The worst case
latency is important now and later.
Looking at it, all we need is one init in vsprintf at boot time and we
are done. That is the third fallout that I am aware of since the rework
of get_random_*().
We managed to get rid of all memory allocations (including GFP_ATOMIC)
from preempt/IRQ-off section on PREEMPT_RT. Therefore I am not convinced
to make all locks in random core a raw_spinlock_t just to make things
work here as of now.

> Jason

Sebastian