Date: Fri, 18 Apr 2014 21:50:46 -0400 From: Thor Lancelot Simon <t...@panix.com>
> 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.