Following backtrace found by robert@'s syzkaller exposes a context /
locking issue related to wsmux's ioctl rwlock:
panic: acquiring blockable sleep lock with spinlock or critical section held
(rwlock) wsmuxlk
trace:
panic+0x15c
witness_checkorder+0x10e0
rw_enter_read+0x66
wsmux_do_displayioctl+0x7e
wsdisplay_emulbell+0x68
wsemul_vt100_output_c0c1+0x2f5
wsemul_vt100_output+0x34e
wsdisplaystart+0x396
ttrstrt+0x4b
timeout_run+0xc4
softclock+0x175
softintr_dispatch+0x107
Xsoftclock+0x1f
Grabbing `sc_lock' should obviously not be possible from softclock context.
I'm not sure what's the best way to fix this issue. timeout_set_proc(9)
will make the warning disappear but is it the right thing to do?
Is there other interrupt-context paths that can enter this code?
The lock has been introduced to prevent access to `sc_cld' in case a
thread was sleeping in the middle of an operation. Are we sure those
sleeping points cannot be reached by entry points from interrupt
context?
Did we consider alternative fixes than a lock?
