Re: [PATCH v6 1/5] random: Blocking API for accessing nonblocking_pool

["Theodore Ts'o" <tytso@mit.edu>]

On Tue, May 19, 2015 at 03:51:55PM +0800, Herbert Xu wrote:
> On Tue, May 19, 2015 at 09:35:15AM +0200, Stephan Mueller wrote:
> > 
> > Thank you for the hints. I will follow your guidance.
> > 
> > Just for my edification: why is this (rather complex sounding) approach 
> > preferred over a simple cancel API? Other async APIs (e.g. the AIO syscalls 
> > with io_cancel) have such cancel operations.
> > 
> > Such cancel function would be as simple as:
> 
> You're right.  The cancel function is indeed simpler.  I can
> certainly live with that.

I'm not at all convinced it's simpler.  I see it add a huge amount of
hair to drivers/char/random.c that is only used by a single caller.

I'm also not sure I understand herbert's suggstion of adding a struct
module to the /dev/random code.  Why is this helpful, and what is the
race that you are trying to protect against?

Finally, this is only going to block *once*, when the system is
initially botting up.  Why is it so important that we get the
asynchronous nature of this right, and why can't we solve it simply by
just simply doing the work in a workqueue, with a completion barrier
getting triggered once /dev/random initializes itself, and just simply
blocking the module unload until /dev/random is initialized?

	     	    	   	 	     - Ted