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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
