Re: [RFC PATCH] drivers/char/random.c: Is reducing locking range like this safe?

["Theodore Ts'o" <tytso@mit.edu>]

On Mon, Jun 09, 2014 at 12:03:55AM -0400, George Spelvin wrote:
> 
> That seems... noticeable.  Causing iterrupt latency problems is defintiely
> a theoretical extrapolation, however.

Actually, if you look very closely, or take a look at the commit
description for 902c098a3663de, you'll see that we're actually
updating the entropy pool from add_interrupt_randomness() w/o taking
any locks.  So that's actually not a problem.

What could be a problem is if we get really unlucky (an interrupt
update happening at the same time as an update from rngd), it's
possible we could end up with an entropy addition getting lost.  It's
not such a big deal if a contribution from add_interrupt_randomness()
gets lost, since we only giving one bit worth of entropy credit.  But
it's possible than a much larger input from rngd could potentially end
up getting overwritten from the fast_pool contribution.

This isn't a disaster per se, but it probably means that it's worth
taking a closer look at how we do the entropy pool mixing input to see
if we can actually a make a fully lockless add_entropy work correctly.
One approach might be to use atomics but of course then we have to
balance the increased overhead of using atomic_t types versus the
locking overhead.

Cheers,

						- Ted