Thanks for taking a look, Xin!

Need ports committer blessing to fix.

Now with patches 'svn add'ed

The changes look straightforward and correct to me, modulo stylistic nits. I agree with everything Mark has already said.

Need secteam approval.

Add default-off (for now) knob to enable/disable the feature

• Add comment to genrandom justifying not rekeying Chacha (caveat, this whole

function is removed in the following differential, but I did try to flesh out a
similar comment in the relevant place there)

Looks great, thanks for doing this!

I think to actually land this, it probably makes sense to hide this behavior behind a non-default tunable. I don't think that complicates things too much, but please discuss. It's certainly a "Relnotes: yes". Is that acceptable from a secteam perspective, @delphij ?

Thanks Mark for taking a look at both of these differentials!

Note that the fast path doesn't work on real systems with SMAP. (It worked in a bhyve VM, of course.) I'm not sure vslock provides sufficient protection against concurrent modification of the UVA to copy directly into it, and the actual difference was not large (2-3%). So I will probably revert that portion. The rest is useful for the follow-up patch, see child revision.

Thanks for doing this! It mostly looks great to me, just some minor const and bool style quibbles below.

Committed in r347888.

Hi Alfonso,

Thanks for reviewing, Xin!

Fix lock recursion; didn't recall that pre_read invoked seeded().

In D20206#435995, @markj wrote:

Where are we calling netdump_enabled() after a panic?

• Add and use netdump_enabled() predicate. We rely on sx_assert neutering

during kdb/panic to obviate the lock assertion during the dump-time code, which
generally does not take locks.

• Refactor de-configuration into netdump_unconfigure() routine
• Rebase on D20233

Tag :)

In D20219#435661, @dgmorris_earthlink.net wrote:

Regarding the live version panic - it is a little odd... __mtx_assert() does check for SCHEDULER_STOPPED... I haven't poked around the live breakpoint in quite a while... wonder if that isn't lit? That would do it. Anyway, I trust you to dig a little deeper on that. Thanks. Otherwise, I'm fine with things.

In D20218#435600, @markj wrote:

Kernel ifuncs are resolved quite early during boot, well before MOD_LOAD.

Huh, I figured linker failure would prevent MOD_LOAD and thus it wouldn't matter. I had thought about providing a 3rd panic function like this but didn't know if it was required and couldn't think of a reason it might be. Guess I was mistaken :-).

So, I think this was an intentional feature and there are automatically generated numerical nodes which are not actually present in the tree structure.

Thanks Mark and Xin!

• Drop ifndef wat
• Drop bangbang "operator" -- bool implicitly coerces on assignment already

Now that some of the dust has settled around random, I'd like to work on getting this in.

In D19948#434568, @jhb wrote:

Correct, in this case the crypto driver would know to not create the session unless it was seeded, so its associated code that invokes arc4random will only be run if the PRNG is seeded, but the check and the arc4random use are in different threads, so TDP_RNG_SEEDED doesn't help.