random_get_pseudo_bytes() should not provide cryptographic strength entropy

Perf profiling of dd on a zvol revealed that my system spent 3.16% of
its time in random_get_pseudo_bytes(). That occurred because the SPL
mapped a Solaris function for generating pseudo-random data to a Linux
function that provides non-blocking cryptographic strength entropy from
the system's entropy pool. Draining the system's entropy pool could
weaken anything using it that requires cryptographic strength entropy,
so we need to obtain pseudo-random data in a way that does not do that.

The Linux kernel did not export a suitable function for this until it
exported get_random_int() in Linux 3.10. While we could implement an
autotools check so that we use it when it is available or even try to
access the symbol on older kernels where it is not exported using the
fact that it is exported on newer ones as justification, we can instead
implement our own pseudo-random data generator. For this purpose, I have
written one based on a pseudo-random number generator proposed in a
paper by Sebastiano Vigna that itself was based on work by the late
George Marsaglia.

http://arxiv.org/pdf/1402.6246v2.pdf

The algorithm presented in the paper expects to operate within a single
threaded environment while the kernel is a multithreaded environment.
This poses the risk that two threads will obtain the same numbers by
running the same routine at the same time. We attempt to avoid this
without using atomic instructions through locking primitives to
serialize access and updatesi by introducing an individualization step
to prevent two threads from obtaining the same numbers. After updating
the seed as is specified in the paper, we take the sum the result of the
generator with the current time and process identifier as the seed for a
second iteration. The second result is not stored, but is instead
returned to the caller as the generator's output.

Profiling the same benchmark with this patch applied showed that time
spent in random_get_pseudo_bytes() dropped to 0.03%. That is a factor of
100 improvement.

Signed-off-by: Richard Yao <ryao@gentoo.org>