[RFC PATCH 0/4] Alternate sclable urandom patchset

[George Spelvin]

Sent as separate patches to make things easier to review; the action is
all in #4.

The first two are minor cleanups I've had in my tree for a while and
felt like working on top of rather than backing out.

The third I'm not happy with, but will serve as a proof-of-concept stub
that I'll rewrite if the rest meets with approval.

Since writing it, I've remembered that we already have a per-CPU "nonce
pool" in the form of the get_random_int_hash array, and I should take
advantage of that.  Another thing I don't like is the mixback is only
160 bits, 80 of which are private.  I'd rather have twice that, if the
read is large enough.  But that requires more code refactoring.

But it does illustrate the basic idea of using a nonce to avoid the
need to do synchronous mixback.  We can do many calls to extract_buf,
from the same or different processors, without doing mixback.

The fourth is where the fun is.

The names of things is certainly up for debate; creating a subclass
of struct entropy_store called "entropy_store_plus" is not my proudest
moment.  I also considered just making the extra fields global variables.
If someone wants to suggest an arrangement that's good for cache line
sharing, that would be appreciated.

But I think the nonblocking_mixback() function came out rather nice.

This uses two locks, rather that the one in the idea I most recently
posted, because add_interrupt_randomness() needs to take the lock,
and I didn't want to force it to do an unbounded amount of mixback
work.

Using two locks avoids the need for interrupt handlers to do
any mixback, and for readers to loop and thus possibly livelock.

George Spelvin (4):
  random: Reduce stack usage in _xfer_secondary_pool
  random: Remove two unused arguments from extract_entropy()
  random: Only do mixback once per read
  random: Make non-blocking mixback non-blocking

 drivers/char/random.c | 218 ++++++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 184 insertions(+), 34 deletions(-)

-- 
2.6.1

--
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/