Remainder of fix for PR kern/51135: if there is an entropy source
that can produce arbitrarily much data, as in rump, then nothing
should ever block indefinitely waiting for data.
Some systems seem to have gotten stuck in a softint processing loop
doing nothing and then trying to do it again. Might fix gson's
frozen qemu/anita sparc autobuilds -- tested on macallan's real sparc
hardware and confirmed to fix at least some freeze at boot.
There are three cases to consider here:
1. You have on-demand synchronous rndsources, e.g. RDRAND (and you're
willing to use it). In that case, you'll just use those whenever you
need to extract entropy. There's no benefit to requesting more from
them when we're entering data into the pool.
2. You have on-demand asynchronous rndsources. These should continue
trying to feed data to the entropy pool as long as it needs more, so
there's no benefit to requesting more from them when we're entering
data into the pool.
3. You don't have any on-demand rndsources. Then rnd_getmore does
nothing, so there's no benefit to calling it.
ok tls
Avoids lock recursion in rndsinks:
rndsink user holds lock
calls rndsink_request
calls rnd_getmore
calls an rndsource callback
calls rnd_add_data
calls rnd_process_events
calls rndsinks_distribute
calls rndsink callback
acquires rndsink user lock.
This can happen only before the rnd_process_events softint is
established, but that's enough to cause a problem and is the main
reason why all our HWRNG drivers are so byzantine (soon to be
fixed!).
ok tls
It is not adjusted everywhere it should be, although the only places
it perhaps formally ought to be are places with questionable entropy
estimates in the first place.
- Make rnd_printing static in kern_rndq.c.
- Merge some #ifdef _KERNEL blocks.
- Fix comments about RND_DEV_(U)RANDOM.
- Move rnd_ready to rnd_private.h.
riastradh