On Sat, Dec 11, 2021 at 10:25:13AM +0000, Visa Hankala wrote: > > Some of these "missing" entries may be caused by transitive lock order > > relations that are not handled by the lock order printer. > > > > I have somewhere a diff that improves the situation. Let's see if I can > > find it... > > Here it is, though I want to tweak it before committing. It has problems > with stack usage because of recursion, and the output is still a mess.
Seems to work /usr/src/regress/sys/ffs/nfs/../tests/chflags/12.t: "chflags returns EROFS if the named file resides on a read-only file system" Running test #0... okay. witness: lock order reversal: 1st 0xfffffd876515e600 vmmaplk (&map->lock) 2nd 0xffff800022b93080 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 lock order (1) &map->lock -> (2) &np->n_lock #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 lock order (2) &np->n_lock -> (3) &ip->i_lock #0 rw_enter+0x65 #1 rrw_enter+0x56 #2 VOP_LOCK+0x5b #3 vn_lock+0xad #4 vrele+0x6a #5 vfs_lookup+0x659 #6 namei+0x245 #7 sys___realpath+0x146 #8 syscall+0x374 #9 Xsyscall+0x128 lock order (3) &ip->i_lock -> (1) &map->lock #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 Running test #1... okay.
