svn commit: r273958 - head/sys/dev/random

Mark R V Murray mark at grondar.org
Sun Nov 2 19:56:14 UTC 2014


> On 2 Nov 2014, at 19:46, Konstantin Belousov <kostikbel at gmail.com> wrote:
> 
>> I don???t quite follow what you mean, but it sounds like you understand
>> the problem. Could you please explain with a bit more detail?
> 
> Which problem ? There are two.
> 
> One is the Adrian' complain. tsleep(9) catches signals, and return
> EINTR/ERESTART when catched.  Typical driver code checks for the
> errors from {t,m}sleep(9) and aborts the operation if error is
> returned.  I.e. you should do
> 	error = tsleep(...);
> 	if (error != 0) {
> 		abort the loop;
> 		return to caller;
> 	}
> The fine detail is that for the case when read has already partially
> progressed, i.e. something was copied out to uio, the error must
> not be returned, but short read performed instead.

OK, I think I follow this.

In another mail you say:
> Yes, this is because error from tsleep() in random_adaptor_read()
> does not abort the loop.  But next loop iteration calls tsleep()
> which returns immediately since there is still pending signal.
> The process continues indefinitely.

.. which supports this what you say further above. Thanks.

> This leads to another question about the code in random_adapter_read():
> if ra_read method sleeps, it must handle the signals as well, return
> error, and the second loop which perorms ra_read/uiomove should be
> aborted as well.  Again, error from either ra_read or uiomove(9)
> must result in short read if something was already copied to uio.
> Currently, there is no error returned by ra_read (or it is ignored),
> and error from uiomove always returned, even if something was already
> copied.

Are you saying the same thing again, or something else? If you are saying
something else, then I am struggling to follow you.

> Second problem is that random_adaptor_lock is owned while tsleep()
> is called (or whatever sleep primitive is used inside ra_read).  If
> platform could only provide randomness through some hw, and module
> is loaded while thread is blocked, module cannot register, while
> reading thread cannot make progress.

I’m sorry, I don’t understand this.

M
-- 
Mark R V Murray



More information about the svn-src-head mailing list