On 28/02/24(Wed) 12:36, Claudio Jeker wrote:
> On Wed, Feb 28, 2024 at 12:26:43PM +0100, Marko Cupać wrote:
> > Hi,
> > 
> > thank you for looking into it, and for the advice.
> > 
> > On Wed, 28 Feb 2024 10:13:06 +0000
> > Stuart Henderson <s...@spacehopper.org> wrote:
> > 
> > > Please try to re-type at least the most important bits from a
> > > screenshot so readers can quickly see which subsystems are involved.
> > 
> > Below is manual transcript of whole screenshot, hopefully no typos.
> > 
> > If you have any advice on what should I do if it happens again in order
> > to get as much info for debuggers as possible, please let me know.
> > 
> > splassert: assertwaitok: want 0 have 4
> > panic: kernel diagnostic assertion "p->p_wchan == NULL" failed: file 
> > "/usr/src/sys/kern/kern_sched.c", line 373
> > Stopped at db_enter+0x14: popq %rbp
> >    TID    PID  UID   PRFLAGS  PFLAGS  CPU  COMMAND
> > 199248  36172  577      0x10       0    1  openvpn
> > 490874  47446    0   0x14000   0x200    2  wg_handshake
> >  71544   9311    0   0x14000   0x200    3  softnet0
> > db_enter() at db_enter+0x14
> > panic(ffffffff820a4b9f) at panic+0xc3
> > __assert(ffffffff82121fcb,ffffffff8209ae5f,175,ffffffff82092fbf) at 
> > assert+0x29
> > sched_chooseproc() at sched_chooseproc+0x26d
> > mi_switch() at mi_switch+0x17f
> > sleep_finish(0,1) at sleep_finish+0x107
> > rw_enter(ffff800008003cf0,2) at rw_enter+0x1ad
> > noise_remote_ready(ffff800008003bf0) at noise_remote_ready+0x33
> > wg_qstart(fff800000a622a8) at wg_qstart+0x18c
> > ifq_serialize(ffff800000a622a8,ffff800000a62390) at ifq_serialize+0xfd
> > hfsc_deferred(ffff800000a62000) at hfsc_deferred+0x68
> > softclock_process_tick_timeout(ffff80000115e248,1) at 
> > softclock_process_tick_timeout+0xfb
> > softclock(0) at softclock+0xb8
> > softintr_dispatch(0) at softintr_dispatch+0xeb
> > end trace frame: 0xffff800020dbc730, count:0
> > 
> 
> WTF! wg(4) is just broken. How the hell should a sleeping rw_lock work
> when called from inside a timeout aka softclock? This is interrupt context
> code is not allowed to sleep there.

It is indeed.  It isn't clear to me why `r_keypair_lock' is a rwlock and
not a mutex.  Does anything sleep in this code?  Why did they pick
sleeping locks in the first place?

Reply via email to