> Date: Sat, 11 Dec 2021 01:13:32 +0100 > From: Alexander Bluhm <[email protected]> > > Hi, > > I have turned on witness during a full regress run on amd64. It > found two issues. Basically I am posting this as baseline, so I > can see if things get better or worse. If someone wants to fix > them, I can dig into the test logs to see which regress triggered > it. > > bluhm > > witness: lock order reversal: > 1st 0xfffffd8774b19310 vmmaplk (&map->lock) > 2nd 0xfffffd872022be68 inode (&ip->i_lock) > lock order "&ip->i_lock"(rrwlock) -> "&map->lock"(rwlock) first seen at: > #0 rw_enter_read+0x38 > #1 uvmfault_lookup+0x8a > #2 uvm_fault_check+0x32 > #3 uvm_fault+0xfc > #4 kpageflttrap+0x12b > #5 kerntrap+0x91 > #6 alltraps_kern_meltdown+0x7b > #7 copyout+0x53 > #8 ffs_read+0x1f6 > #9 VOP_READ+0x41 > #10 vn_rdwr+0xa1 > #11 vmcmd_map_readvn+0xa6 > #12 exec_process_vmcmds+0x84 > #13 sys_execve+0x77d > #14 start_init+0x29f > #15 proc_trampoline+0x1c > lock order "&map->lock"(rwlock) -> "&ip->i_lock"(rrwlock) first seen at: > #0 rw_enter+0x65 > #1 rrw_enter+0x56 > #2 VOP_LOCK+0x5b > #3 vn_lock+0xad > #4 uvn_io+0x1cc > #5 uvm_pager_put+0xe6 > #6 uvn_flush+0x250 > #7 uvm_map_clean+0x1ff > #8 syscall+0x374 > #9 Xsyscall+0x128
This one may be harmless. The first backtrace is from executing init(8), which only happens once and happens in a somewhat strange manner. > witness: lock order reversal: > 1st 0xfffffd886921d8d8 vmmaplk (&map->lock) > 2nd 0xffff800022c54130 nfsnode (&np->n_lock) > lock order data w2 -> w1 missing > lock order "&map->lock"(rwlock) -> "&np->n_lock"(rrwlock) first seen at: > #0 rw_enter+0x65 > #1 rrw_enter+0x56 > #2 VOP_LOCK+0x5b > #3 vn_lock+0xad > #4 vn_rdwr+0x7f > #5 vndstrategy+0x2e6 > #6 physio+0x227 > #7 spec_write+0x95 > #8 VOP_WRITE+0x41 > #9 vn_write+0xfc > #10 dofilewritev+0x14d > #11 sys_pwrite+0x5c > #12 syscall+0x374 > #13 Xsyscall+0x128 so this is accessing a vnd whichis backed by a file on NFS. Not terribly surprised that this causes issues. I think: > lock order "&map->lock"(rwlock) -> "&np->n_lock"(rrwlock) first seen at: is the "right" lock order. Unfortunately data for the "wrong" order is missing...
