random.4: Describe handling of O_NONBLOCK

/dev/random and /dev/urandom treat O_NONBLOCK differently.
This should be described in the manpage.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

man4/random.4

@@ -44,6 +44,22 @@ pool.
 high quality randomness such as one-time pad or key generation.
 When the entropy pool is empty, reads from \fI/dev/random\fP will block
 until additional environmental noise is gathered.
+If
+.BR open (2)
+is called for
+.I /dev/random
+with flag
+.BR O_NONBLOCK ,
+a subsequent
+.BR read (2)
+will not block if the requested number of bytes is not available.
+Instead the available bytes are returned.
+If no byte is available
+.BR read (2)
+will return -1 and
+.I errno
+will be set to
+.BR EAGAIN .
 .LP
 A read from the \fI/dev/urandom\fP device will not block
 waiting for more entropy.
@@ -55,6 +71,15 @@ literature, but it is theoretically possible that such an attack may
 exist.
 If this is a concern in your application, use \fI/dev/random\fP
 instead.
+.B O_NONBLOCK
+has no effect when opening
+.IR /dev/urandom .
+When calling
+.BR read (2)
+for device
+.I /dev/urandom
+signals will not be handled until after the requested random bytes
+have been generated.
 .LP
 Writing to \fI/dev/random\fP or \fI/dev/urandom\fP will update the
 entropy pool with the data written, but this will not result in a