On Mon, Apr 22, 2024 at 04:18:46PM +0200, Mark Kettenis wrote: > > Date: Mon, 22 Apr 2024 15:39:55 +0200 > > From: Alexander Bluhm <bl...@openbsd.org> > > > > Hi, > > > > I see a witness lock order reversal warning with soreceive. It > > happens during NFS regress tests. In /var/log/messages is more > > context from regress. > > > > Apr 22 03:18:08 ot29 /bsd: uid 0 on > > /mnt/regress-ffs/fstest_49fd035b8230791792326afb0604868b: out of inodes > > Apr 22 03:18:21 ot29 mountd[6781]: Bad exports list line > > /mnt/regress-nfs-server > > Apr 22 03:19:08 ot29 /bsd: witness: lock order reversal: > > Apr 22 03:19:08 ot29 /bsd: 1st 0xfffffd85c8ae12a8 vmmaplk (&map->lock) > > Apr 22 03:19:08 ot29 /bsd: 2nd 0xffff80004c488c78 nfsnode (&np->n_lock) > > Apr 22 03:19:08 ot29 /bsd: lock order data w2 -> w1 missing > > Apr 22 03:19:08 ot29 /bsd: lock order "&map->lock"(rwlock) -> > > "&np->n_lock"(rrwlock) first seen at: > > Apr 22 03:19:08 ot29 /bsd: #0 rw_enter+0x6d > > Apr 22 03:19:08 ot29 /bsd: #1 rrw_enter+0x5e > > Apr 22 03:19:08 ot29 /bsd: #2 VOP_LOCK+0x5f > > Apr 22 03:19:08 ot29 /bsd: #3 vn_lock+0xbc > > Apr 22 03:19:08 ot29 /bsd: #4 vn_rdwr+0x83 > > Apr 22 03:19:08 ot29 /bsd: #5 vndstrategy+0x2ca > > Apr 22 03:19:08 ot29 /bsd: #6 physio+0x204 > > Apr 22 03:19:08 ot29 /bsd: #7 spec_write+0x9e > > Apr 22 03:19:08 ot29 /bsd: #8 VOP_WRITE+0x45 > > Apr 22 03:19:08 ot29 /bsd: #9 vn_write+0x100 > > Apr 22 03:19:08 ot29 /bsd: #10 dofilewritev+0x14e > > Apr 22 03:19:08 ot29 /bsd: #11 sys_pwrite+0x60 > > Apr 22 03:19:08 ot29 /bsd: #12 syscall+0x588 > > Apr 22 03:19:08 ot29 /bsd: #13 Xsyscall+0x128 > > You're not talking about this one isn't it? > > > Apr 22 03:19:08 ot29 /bsd: witness: lock order reversal: > > Apr 22 03:19:08 ot29 /bsd: 1st 0xfffffd85c8ae12a8 vmmaplk (&map->lock) > > Apr 22 03:19:08 ot29 /bsd: 2nd 0xffff80002ec41860 sbufrcv > > (&so->so_rcv.sb_lock) > > Apr 22 03:19:08 ot29 /bsd: lock order "&so->so_rcv.sb_lock"(rwlock) -> > > "&map->lock"(rwlock) first seen at: > > Apr 22 03:19:08 ot29 /bsd: #0 rw_enter_read+0x50 > > Apr 22 03:19:08 ot29 /bsd: #1 uvmfault_lookup+0x8a > > Apr 22 03:19:08 ot29 /bsd: #2 uvm_fault_check+0x36 > > Apr 22 03:19:08 ot29 /bsd: #3 uvm_fault+0xfb > > Apr 22 03:19:08 ot29 /bsd: #4 kpageflttrap+0x158 > > Apr 22 03:19:08 ot29 /bsd: #5 kerntrap+0x94 > > Apr 22 03:19:08 ot29 /bsd: #6 alltraps_kern_meltdown+0x7b > > Apr 22 03:19:08 ot29 /bsd: #7 copyout+0x57 > > Apr 22 03:19:08 ot29 /bsd: #8 soreceive+0x99a > > Apr 22 03:19:08 ot29 /bsd: #9 recvit+0x1fd > > Apr 22 03:19:08 ot29 /bsd: #10 sys_recvfrom+0xa4 > > Apr 22 03:19:08 ot29 /bsd: #11 syscall+0x588 > > Apr 22 03:19:08 ot29 /bsd: #12 Xsyscall+0x128 > > Apr 22 03:19:08 ot29 /bsd: lock order data w1 -> w2 missing > > Unfortunately we don't see the backtrace for the reverse lock order. > So it is hard to say something sensible. Without more information I'd > say that taking "&so->so_rcv.sb_lock" before "&map->lock" is the > correct lock order. >
I suspect the same issue for so_snd. > > Apr 22 03:22:27 ot29 /bsd: uid 0 on > > /mnt/regress-nfs-client/fstest_3372ae0ca77c9470440ef577e4f5e16e: file > > system full > > Apr 22 03:22:30 ot29 /bsd: uid 0 on > > /mnt/regress-nfs-client/fstest_632a6ba698de06560b4c93617b00808d: out of > > inodes > > > > According to timestamp it is regress/sys/ffs. > > make -C /usr/src/regress/sys/ffs/nfs run-chmod > > triggers it. > > > > I already reported in a thread on tech@, but the issue is independent > > of the diff over there. Let's start a fresh discussion. > > > > bluhm > > > > >
