On Mon, Apr 26, 2021 at 08:58:32AM +0200, Anton Lindqvist wrote: > On Sat, Apr 24, 2021 at 06:00:35PM -0600, Vitaliy Makkoveev wrote: > > CVSROOT: /cvs > > Module name: src > > Changes by: m...@cvs.openbsd.org 2021/04/24 18:00:35 > > > > Modified files: > > sys/kern : uipc_socket.c uipc_socket2.c > > sys/net : rtsock.c > > sys/sys : socketvar.h > > > > Log message: > > Implement per-socket `so_lock' rwlock(9) and use it to protect routing > > (PF_ROUTE) sockets. This can be done because we have no cases where one > > thread should lock two sockets simultaneously. > > > > Also this time `so_lock 'used for routing sockets only but in the future > > it will be used to other socket types too. > > > > ok bluhm@ > > syzkaller found a new witness issue, is this commit the root cause? > > HEAD commit: b0cb8ce4 Asus USB-N10 should work with urtwn(4). Patch by .. > git tree: openbsd > console output: https://syzkaller.appspot.com/x/log.txt?x=10612ccdd00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=bf87b6915a88cd0d > dashboard link: https://syzkaller.appspot.com/bug?extid=eb593ee96235d71ade89 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+eb593ee96235d71ad...@syzkaller.appspotmail.com > > login: panic: acquiring blockable sleep lock with spinlock or critical > section held (rwlock) solock > Stopped at db_enter+0x18: addq $0x8,%rsp > TID PID UID PRFLAGS PFLAGS CPU COMMAND > db_enter() at db_enter+0x18 sys/arch/amd64/amd64/db_interface.c:398 > panic(ffffffff823e90cf) at panic+0x15e sys/kern/subr_prf.c:218 > witness_checkorder(fffffd806daa87a8,9,0) at witness_checkorder+0x1188 > sys/kern/subr_witness.c:833 > rw_enter_write(fffffd806daa8798) at rw_enter_write+0x5b > sys/kern/kern_rwlock.c:128 > solock(fffffd806daa8790) at solock+0x97 sys/kern/uipc_socket2.c:299 > rtm_senddesync_timer(fffffd806daa8790) at rtm_senddesync_timer+0x1a > sys/net/rtsock.c:454 > timeout_run(fffffd8074008810) at timeout_run+0xcc sys/kern/kern_timeout.c:674 > softclock_process_tick_timeout(fffffd8074008810,0) at > softclock_process_tick_timeout+0x196 sys/kern/kern_timeout.c:721 > softclock(0) at softclock+0x11a sys/kern/kern_timeout.c:752 > softintr_dispatch(0) at softintr_dispatch+0xfb > sys/arch/amd64/amd64/softintr.c:90 > Xsoftclock() at Xsoftclock+0x1f > acpicpu_idle() at acpicpu_idle+0x2eb sys/dev/acpi/acpicpu.c:1206 > sched_idle(ffffffff8272eff0) at sched_idle+0x417 sys/kern/kern_sched.c:178 > end trace frame: 0x0, count: 2
It is not correct to grab a rwlock from a timeout callback. The timeout callback can not sleep (since there is no process context). This needs to use a taskq as in use timeout_set_flags() and TIMEOUT_PROC. -- :wq Claudio
