Messages in this thread | | | Date | Mon, 9 Jun 2014 09:34:48 -0400 | From | Theodore Ts'o <> | Subject | Re: [RFC PATCH] drivers/char/random.c: Is reducing locking range like this safe? |
| |
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
| |