New Lock Order Reversal in 12.0-current?

topcat

topcat

Hi, I'm running 12.0-current and noticed a LOR message from WITNESS which I couldn't find a report about. I looked at http://sources.zabbadoz.net/freebsd/lor.html, among other places.

system details:
Code: 
root@triskelion:~ # uname -a
FreeBSD triskelion 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r311461: Thu Jan  5 22:46:38 UTC 2017     root@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
root@triskelion:~ # freebsd-version
12.0-CURRENT

WITNESS report:
Code: 
lock order reversal:
 1st 0xfffff8002e8049a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2598
 2nd 0xfffffe01e7ce9b40 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:277
 3rd 0xfffff8002ec7b9a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2598
stack backtrace:
#0 0xffffffff80aa6fd0 at witness_debugger+0x70
#1 0xffffffff80aa6ed3 at witness_checkorder+0xde3
#2 0xffffffff80a20c15 at __lockmgr_args+0x725
#3 0xffffffff80d06fc5 at ffs_lock+0xa5
#4 0xffffffff8101c0c0 at VOP_LOCK1_APV+0xe0
#5 0xffffffff80b1a6aa at _vn_lock+0x9a
#6 0xffffffff80b0ac94 at vget+0x64
#7 0xffffffff80afd19c at vfs_hash_get+0xcc
#8 0xffffffff80d02e5e at ffs_vgetf+0x3e
#9 0xffffffff80cf9787 at softdep_sync_buf+0xc37
#10 0xffffffff80d07c51 at ffs_syncvnode+0x2a1
#11 0xffffffff80d06e60 at ffs_fsync+0x20
#12 0xffffffff8101b110 at VOP_FSYNC_APV+0xe0
#13 0xffffffff80d0f2f0 at ufs_direnter+0x870
#14 0xffffffff80d18050 at ufs_makeinode+0x5c0
#15 0xffffffff80d13d7a at ufs_create+0x3a
#16 0xffffffff810199ca at VOP_CREATE_APV+0xda
#17 0xffffffff80b19f77 at vn_open_cred+0x2c7
This is based on the FreeBSD-12.0-CURRENT-amd64-20170105-r311461-memstick.img installer. Known issue?

It happened during a portsnap fetch. the filesystem is UFS with default mount options.
 
I've got a little chat going here. This is probably not an actual bug, (WITNESS has false positives sometimes) but it's bugging me a bit ;).
 
Yes, I see this too on 12-current
Code: 
lock order reversal:
 1st 0xfffff800715e0428 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:923
 2nd 0xfffff800712a0428 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2572
stack backtrace:
#0 0xffffffff80bd7df3 at witness_debugger+0x73
#1 0xffffffff80bd7c74 at witness_checkorder+0xe34
#2 0xffffffff80b4618b at lockmgr_lock_fast_path+0x18b
#3 0xffffffff811ca849 at VOP_LOCK1_APV+0xd9
#4 0xffffffff80c53946 at _vn_lock+0x66
#5 0xffffffff80c4230f at vget+0x7f
#6 0xffffffff80a38aed at devfs_allocv+0xdd
#7 0xffffffff80a385e3 at devfs_root+0x43
#8 0xffffffff80c3976d at vfs_domount+0x9cd
#9 0xffffffff80c38797 at vfs_donmount+0x7f7
#10 0xffffffff80c37f72 at sys_nmount+0x72
#11 0xffffffff81041eec at amd64_syscall+0x2cc
#12 0xffffffff8101c8fd at fast_syscall_common+0x101
 
It would probably be a good idea to attract the attention of a kernel VFS and file system developer to these messages. They may indicate ... a lock order problem (duh!). From the point of view of a developer trying to find potential bugs in the kernel, this might be serious. From the point of view of an end user, they are probably just an annoyance, or perhaps even irrelevant.

Question for mods and admins: How does one get the attention of the kernel developers, for something that isn't as serious as a bug report? There was a person who maintained a list of kernel lock order reports at the zabbadoz.net page mentioned above, but it has not been updated since 2009, so contacting that person is probably pointless.
 
You must log in or register to reply here.
Back
Top