locks and kernel randomness...

[Konstantin Belousov]

On Mon, Feb 23, 2015 at 05:20:26PM -0800, John-Mark Gurney wrote:
> I'm working on simplifying kernel randomness interfaces.  I would like
> to get read of all weak random generators, and this means replacing
> read_random and random(9) w/ effectively arc4rand(9) (to be replaced
> by ChaCha or Keccak in the future).
> 
> The issue is that random(9) is called from any number of contexts, such
> as the scheduler.  This makes locking a bit more interesting.  Currently,
> both arc4rand(9) and yarrow/fortuna use a default mtx lock to protect
> their state.  This obviously isn't compatible w/ the scheduler, and
> possibly other calling contexts.
> 
> I have a patch[1] that unifies the random interface.  It converts a few
> of the locks from mtx default to mtx spin to deal w/ this.
This is definitely an overkill. The rebalancing minor use of randomness
absolutely does not require cryptographical-strenght randomness to
select a moment to rebalance thread queue. Imposing the spin lock on
the whole random machinery just to allow the same random gathering code
to be used for balance_ticks is detriment to the system responsivness.
Scheduler is fine even with congruential generators, as you could see in
the cpu_search(), look for the '69069'.

Please do not enforce yet another spinlock for the system.