cprng_fast and interrupts [was Re: Patch: cprng_fast performance - please review.]

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

   Date: Fri, 18 Apr 2014 21:50:46 -0400
   From: Thor Lancelot Simon <tls%panix.com@localhost>

   > Are there actually any callers of cprng_fast at IPL_HIGH?  Are there
   > actually any legitimate random decisions to be made at IPL_HIGH?  I'm
   > sceptical.

   What do you get if you cross an elephant and a rhinocerous?  Given that
   what we do within the spl* takes very little time I am inclined to say
   what spl we go to hardly matters, and be very conservative.  The real
   question here, I think, is whether we should spl*() at all, or forbid
   use of cprng_fast() from interrupt context entirely.

In partial answer to my question, there are calls to libc/libkern
random at IPL_HIGH in various statistical clock interrupt handlers, so
if we want to replace that by cprng_fast we shall need it to work at
IPL_HIGH (which currently it doesn't really!).

There are also many calls to cprng_fast throughout the network stack,
certainly in softint handlers if not also in hard interrupt handlers,
so we need cprng_fast to work at IPL_SOFTNET if not IPL_VM.

Certainly we should not do more than a small constant amount of
computation with interrupts blocked.  For IPL_VM, hundreds or even a
couple thousands of cycles of crypto are probably acceptable -- we
already do, e.g., red/black tree operations at IPL_VM.

But what is the maximum acceptable latency at IPL_HIGH?  Is, say, 400
cycles too long to block interrupts?  Is that too slow for statclock
interrupts?  (Should we have guidelines for these written down?)

Much as I want to discourage the use of non-cryptographic PRNGs for
any purpose, I am willing to entertain the notion that the statclock
interrupt handler may be adequately serviced by an LCG or LFSR too.