[I CC'd Bryan D. in case this is related to the failed rm activity tied to disamounts that are not happening first. I had reported on an example.]
I got the following from poudriere-devel activity on a system running a pkgbase main debug kernel. Note that nullfs_unmount and null_lock are also involved: lock order reversal: 1st 0xffffa0009027d3f0 ufs (ufs, lockmgr) @ /home/pkgbuild/worktrees/main/sys/kern/vfs_mount.c:2260 2nd 0xffffa000903b05b0 tmpfs (tmpfs, lockmgr) @ /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:4172 lock order tmpfs -> ufs established at: #0 0xffff00000052708c at witness_checkorder+0x344 #1 0xffff00000047d0b8 at lockmgr_lock_flags+0x1fc #2 0xffff0000007d43bc at ffs_lock+0x64 #3 0xffff000156483cd8 at null_lock+0xb4 #4 0xffff0000005c0ab0 at _vn_lock+0x58 #5 0xffff0000005aa5c0 at vflush+0x138 #6 0xffff000156482a94 at nullfs_unmount+0x3c #7 0xffff00000059f040 at dounmount+0x714 #8 0xffff00000059e8c4 at kern_unmount+0x298 #9 0xffff00000086cee4 at do_el0_sync+0x5dc #10 0xffff00000084493c at handle_el0_sync+0x4c lock order ufs -> tmpfs attempted at: #0 0xffff00000052782c at witness_checkorder+0xae4 #1 0xffff00000047d0b8 at lockmgr_lock_flags+0x1fc #2 0xffff0000005c0ab0 at _vn_lock+0x58 #3 0xffff0000005aa5c0 at vflush+0x138 #4 0xffff0000003dc280 at tmpfs_unmount+0x58 #5 0xffff00000059f040 at dounmount+0x714 #6 0xffff00000059e8c4 at kern_unmount+0x298 #7 0xffff00000086cee4 at do_el0_sync+0x5dc #8 0xffff00000084493c at handle_el0_sync+0x4c It is not always obvious when lock order reversal notices are significant. Sorry if this is just noise. The context happened to be an aarch64 system doing armv7 poudriere bulk build activity. For reference (outside the jail/chroot): # uname -apKU FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT main-n271137-d68d12481778 GENERIC arm64 aarch64 1500019 1500019 That is from: .snap20240711212638 The armv7 jail directory tree is from: .snap20240711211723 === Mark Millard marklmi at yahoo.com
