On Sat, Dec 11, 2021 at 09:58:54AM +0100, Mark Kettenis wrote: > > Date: Sat, 11 Dec 2021 01:13:32 +0100 > > From: Alexander Bluhm <alexander.bl...@gmx.net>
> > 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... 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...
