Now that the SCHED_LOCK() is a mutex I see the following WITNESS report on arm64.
witness: lock order reversal: 1st 0xffffff80012486e8 /usr/src/sys/dev/rnd.c:321 (/usr/src/sys/dev/rnd.c:321) 2nd 0xffffff800120afb0 /usr/src/sys/kern/kern_timeout.c:57 (/usr/src/sys/kern/kern_timeout.c:57) lock order [1] /usr/src/sys/dev/rnd.c:321 (/usr/src/sys/dev/rnd.c:321) -> [2] /usr/src/sys/kern/kern_timeout.c:57 (/usr/src/sys/kern/kern_timeout.c:57) #0 mtx_enter+0x48 #1 timeout_del+0x30 #2 dequeue_randomness+0x3c #3 extract_entropy+0x94 #4 _rs_stir+0x2c #5 arc4random_buf+0x108 #6 pool_p_alloc+0x10c #7 pool_do_get+0x210 #8 pool_get+0x88 #9 amap_alloc1+0xec #10 amap_alloc+0x3c #11 amap_copy+0x11c #12 uvm_fault_check+0x270 #13 uvm_fault+0xd8 #14 udata_abort+0x13c #15 do_el0_sync+0x134 #16 handle_el0_sync+0x74 lock order [2] /usr/src/sys/kern/kern_timeout.c:57 (/usr/src/sys/kern/kern_timeout.c:57) -> [3] &sched_lock (&sched_lock) #0 mtx_enter+0x48 #1 sleep_setup+0x5c #2 msleep+0x9c #3 softclock_thread+0xb4 #4 proc_trampoline+0x10 lock order [3] &sched_lock (&sched_lock) -> [4] /usr/src/sys/arch/arm64/arm64/pmap.c:221 (/usr/src/sys/arch/arm64/arm64/pmap.c:221) #0 mtx_enter+0x48 #1 pmap_allocate_asid+0x20 #2 pmap_setttb+0x4c #3 $x.2+0x38 #4 sleep_finish+0xf4 #5 main+0x438 #6 virtdone+0x74 lock order [4] /usr/src/sys/arch/arm64/arm64/pmap.c:221 (/usr/src/sys/arch/arm64/arm64/pmap.c:221) -> [1] /usr/src/sys/dev/rnd.c:321 (/usr/src/sys/dev/rnd.c:321) #0 mtx_enter+0x48 #1 arc4random+0x2c #2 pmap_find_asid+0x70 #3 pmap_allocate_asid+0x28 #4 pmap_setttb+0x4c #5 $x.2+0x38 #6 sleep_finish+0xf4 #7 main+0x438 #8 virtdone+0x74
