Bug 257439

This lock order reversal is shown at after unmounting a UFS fs.

I have been able to isolate two scenarios:
1) ZFS root, mount an external UFS, then unmount it
lock order reversal:
 1st 0xffffa00061bb3070 zfs (zfs, lockmgr) @ /usr/src/sys/kern/vfs_mount.c:1817
 2nd 0xffffa0201d280e70 devfs (devfs, lockmgr) @ /usr/src/sys/kern/vfs_subr.c:3251
lock order devfs -> zfs established at:
#0 0xffff0000004e091c at witness_checkorder+0x434
#1 0xffff0000004443e4 at lockmgr_xlock+0x50
#2 0xffff00000056ee98 at _vn_lock+0x54
#3 0xffff00000054f840 at vfs_domount+0xda4
#4 0xffff00000054d870 at vfs_donmount+0x2b8
#5 0xffff0000005522f8 at kernel_mount+0x4c
#6 0xffff000000554a50 at parse_mount+0x49c
#7 0xffff0000005532d0 at vfs_mountroot+0x6f0
#8 0xffff0000003ffb80 at start_init+0x24
#9 0xffff00000042cbdc at fork_exit+0x74
#10 0xffff0000007794dc at fork_trampoline+0x14
lock order zfs -> devfs attempted at:
#0 0xffff0000004e10f4 at witness_checkorder+0xc0c
#1 0xffff000000442984 at lockmgr_lock_flags+0x1e4
#2 0xffff00000056ee98 at _vn_lock+0x54
#3 0xffff000000559634 at vput_final+0x180
#4 0xffff0000006eda34 at ffs_unmount+0x2fc
#5 0xffff000000550910 at dounmount+0x43c
#6 0xffff00000055048c at kern_unmount+0x2d4
#7 0xffff000000779dd0 at do_el0_sync+0x4b8
#8 0xffff000000759a1c at handle_el0_sync+0x90


2) UFS root (in this case the lor shows at shutdown).
lock order reversal:
 1st 0xffffa0000b476770 ufs (ufs, lockmgr) @ /mnt/usr/src/sys/kern/vfs_mount.c:1817
 2nd 0xffffa0000aa9ce70 devfs (devfs, lockmgr) @ /mnt/usr/src/sys/kern/vfs_subr.c:3009
lock order devfs -> ufs established at:
#0 0xffff0000004e0ba0 at witness_checkorder+0x434
#1 0xffff000000442b90 at lockmgr_lock_flags+0x1e4
#2 0xffff0000006efe28 at ffs_lock+0x64
#3 0xffff00000056f18c at _vn_lock+0x54
#4 0xffff00000054fac4 at vfs_domount+0xda4
#5 0xffff00000054daf4 at vfs_donmount+0x2b8
#6 0xffff00000055257c at kernel_mount+0x4c
#7 0xffff000000554cd4 at parse_mount+0x49c
#8 0xffff000000553554 at vfs_mountroot+0x6f0
#9 0xffff0000003ffd84 at start_init+0x24
#10 0xffff00000042cde8 at fork_exit+0x74
#11 0xffff00000077a8ac at fork_trampoline+0x14
lock order ufs -> devfs attempted at:
#0 0xffff0000004e1378 at witness_checkorder+0xc0c
#1 0xffff0000004445f0 at lockmgr_xlock+0x50
#2 0xffff00000056f18c at _vn_lock+0x54
#3 0xffff0000005591a4 at vget_finish+0x4c
#4 0xffff00000031b9d0 at devfs_allocv+0xd0
#5 0xffff00000031b15c at devfs_root+0x44
#6 0xffff00000055e638 at vfs_cache_root_fallback+0x15c
#7 0xffff00000055a490 at vflush+0x5c
#8 0xffff00000031b064 at devfs_unmount+0x34
#9 0xffff000000550b94 at dounmount+0x43c
#10 0xffff00000055bc64 at vfs_unmountall+0xcc
#11 0xffff00000052eaa4 at bufshutdown+0x288
#12 0xffff000000473be8 at kern_reboot+0x234
#13 0xffff000000473950 at sys_reboot+0x358
#14 0xffff00000077b1a0 at do_el0_sync+0x4b8
#15 0xffff00000075a21c at handle_el0_sync+0x90

All this is on a recent current:
# uname -a
FreeBSD asn 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n248066-439097486ba0: Tue Jul 20 13:26:37 CEST 2021     root@asn:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm64

This is similar to bug #256868 but I reported it independently because it happens on different circumstances.

I am unable to test CURRENT on an hardware != aarch64, so I am reporting the bug for this hardware, but the lor might show up on different hardware as well.


Is this known? Shall it be reported? There is an outaded page http://sources.zabbadoz.net/freebsd/lor.html and I don't see this exact LOR there...