Re: Revising prandom_32 generator

[George Spelvin <lkml@sdf.org>]

> A little backstory.  I started the prandom_32 stuff long ago when I wanted
> a better (longer period) PRNG for use in netem. Took the existing code from
> older version of GNU scientific library (pre GPLv3).  If there is something
> faster with better properties go for it. But the whole point of prandom_32
> is that it doesn't have to be crypto quality.

Than you for the encouragement!  The lfsr113 generator is really
a perfectly respectable generator.  There's nothing about it that
"needs fixing"; it's just possible to do slighty better.

When I can get better statistics, longer period (for the same state
size), faster *and* smaller code size, it seems worth looking into.

And yes, I understand "pseudorandom" very well.  From a documentation
patch for drivers/char/random.c I also posted recenty:
+ *
+ * prandom_u32()
+ * -------------
+ *
+ * For even weaker applications, see the pseudorandom generator
+ * prandom_u32(), prandom_max(), and prandom_bytes().  If the random
+ * numbers aren't security-critical at all, these are *far* cheaper.
+ * Useful for self-tests, random error simulation, randomized backoffs,
+ * and any other application where you trust that nobody is trying to
+ * maliciously mess with you by guessing the "random" numbers.