Change Details

This LOR happens when reading from a file backed MD device: lock order reversal: 1st 0xfffffe00431eaac0 pbufwait (pbufwait, lockmgr) @ /cobra/src/sys/vm/vm_pager.c:471 2nd 0xfffff80003f17930 ufs (ufs, lockmgr) @ /cobra/src/sys/dev/md/md.c:977 lock order pbufwait -> ufs attempted at: #0 0xffffffff80c78ead at witness_checkorder+0xbdd #1 0xffffffff80bd6a52 at lockmgr_lock_flags+0x182 #2 0xffffffff80f52d5c at ffs_lock+0x6c #3 0xffffffff80d0f3f4 at _vn_lock+0x54 #4 0xffffffff80708629 at mdstart_vnode+0x499 #5 0xffffffff807060ec at md_kthread+0x20c #6 0xffffffff80bbfcd0 at fork_exit+0x80 #7 0xffffffff810b809e at fork_trampoline+0xe 1+0 records in 1+0 records out 512 bytes transferred in 0.008936 secs (57298 bytes/sec) This LOR was previously blessed by witness before commit: 531f8cfea06b ("Use dedicated lock name for pbufs") I considered blessing ufs and pbufwait in the witness code, but wasn't sure that was the correct fix. I read 5875b94c7493 ("buf_alloc(): lock the buffer with LK_NOWAIT"), hence the same suggested fix for pbuf_ctor(). While the buffer is not freshly allocated, it seems reasonable to assume that LK_NOWAIT will also be a nop here since BUF_UNLOCK() happens in pbuf_dtor().

This LOR happens when reading from a file backed MD device: % truncate -s 100M gdev.img % mdconfig -f gdev.img md0 % dd if=/dev/md0 of=/dev/null count=1 bs=512 lock order reversal: 1st 0xfffffe00431eaac0 pbufwait (pbufwait, lockmgr) @ /cobra/src/sys/vm/vm_pager.c:471 2nd 0xfffff80003f17930 ufs (ufs, lockmgr) @ /cobra/src/sys/dev/md/md.c:977 lock order pbufwait -> ufs attempted at: #0 0xffffffff80c78ead at witness_checkorder+0xbdd #1 0xffffffff80bd6a52 at lockmgr_lock_flags+0x182 #2 0xffffffff80f52d5c at ffs_lock+0x6c #3 0xffffffff80d0f3f4 at _vn_lock+0x54 #4 0xffffffff80708629 at mdstart_vnode+0x499 #5 0xffffffff807060ec at md_kthread+0x20c #6 0xffffffff80bbfcd0 at fork_exit+0x80 #7 0xffffffff810b809e at fork_trampoline+0xe 1+0 records in 1+0 records out 512 bytes transferred in 0.008936 secs (57298 bytes/sec) This LOR was previously blessed by witness before commit 531f8cfea06b ("Use dedicated lock name for pbufs") I considered blessing ufs and pbufwait in the witness code, but wasn't sure that was the correct fix. I read 5875b94c7493 ("buf_alloc(): lock the buffer with LK_NOWAIT"), hence the same suggested fix for pbuf_ctor(). While the buffer is not freshly allocated, it seems reasonable to assume that LK_NOWAIT will also be a nop here since BUF_UNLOCK() happens in pbuf_dtor().

This LOR happens when reading from a file backed MD device: % truncate -s 100M gdev.img % mdconfig -f gdev.img md0 % dd if=/dev/md0 of=/dev/null count=1 bs=512 lock order reversal: 1st 0xfffffe00431eaac0 pbufwait (pbufwait, lockmgr) @ /cobra/src/sys/vm/vm_pager.c:471 2nd 0xfffff80003f17930 ufs (ufs, lockmgr) @ /cobra/src/sys/dev/md/md.c:977 lock order pbufwait -> ufs attempted at: #0 0xffffffff80c78ead at witness_checkorder+0xbdd #1 0xffffffff80bd6a52 at lockmgr_lock_flags+0x182 #2 0xffffffff80f52d5c at ffs_lock+0x6c #3 0xffffffff80d0f3f4 at _vn_lock+0x54 #4 0xffffffff80708629 at mdstart_vnode+0x499 #5 0xffffffff807060ec at md_kthread+0x20c #6 0xffffffff80bbfcd0 at fork_exit+0x80 #7 0xffffffff810b809e at fork_trampoline+0xe 1+0 records in 1+0 records out 512 bytes transferred in 0.008936 secs (57298 bytes/sec) This LOR was previously blessed by witness before commit: 531f8cfea06b ("Use dedicated lock name for pbufs") I considered blessing ufs and pbufwait in the witness code, but wasn't sure that was the correct fix. I read 5875b94c7493 ("buf_alloc(): lock the buffer with LK_NOWAIT"), hence the same suggested fix for pbuf_ctor(). While the buffer is not freshly allocated, it seems reasonable to assume that LK_NOWAIT will also be a nop here since BUF_UNLOCK() happens in pbuf_dtor().