All of lore.kernel.org
 help / color / mirror / Atom feed
* random: locking vs. lockless accesses
@ 2013-11-11 19:52 Greg Price
  0 siblings, 0 replies; only message in thread
From: Greg Price @ 2013-11-11 19:52 UTC (permalink / raw)
  To: Theodore Ts'o; +Cc: linux-kernel, Jiri Kosina

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2013-11-11 19:52 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-11 19:52 random: locking vs. lockless accesses Greg Price

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.