random: locking vs. lockless accesses

From: Greg Price
Date: Mon Nov 11 2013 - 14:52:30 EST


Hi Ted,

After reading through the RNG code, I'm curious about one aspect and I
wonder if you can shed light on it. Since v3.6-rc1~26^2~30 ("random:
use lockless techniques in the interrupt path"), we mix bytes into the
pool without taking the lock, when inside add_interrupt_randomness().
This means we may mix concurrently with mixing from other input
sources or with hashing the pool in extract_buf(). Nevertheless we
still take the lock in those other situations.

What do you think are the consequences of accessing the pool
concurrently? If it's OK to do, should we be doing so everywhere?

By my reading, the only mutable data on a pool that we consistently
protect with the lock is ->last_data and ->last_data_init. If
everything else were accessed without the lock, the only lock-taking
that would survive is what we do in extract_entropy when fips_enabled
is true.

Thanks, cheers,
Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/