New LOR: lock order reversal: 1st 0xffffffff807417c0 allproc (allproc) @ /usr/src/sys/vm/vm_meter.c:130 2nd 0xffffff002c263ba8 zfs (zfs) @ /usr/src/sys/kern/vfs_subr.c:2188 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2c witness_checkorder() at witness_checkorder+0x66f __lockmgr_args() at __lockmgr_args+0x475 vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x52 _vn_lock() at _vn_lock+0x47 vrele() at vrele+0xc3 vm_object_deallocate() at vm_object_deallocate+0x1ad _vm_map_unlock() at _vm_map_unlock+0x70 vm_map_remove() at vm_map_remove+0x6f vmspace_free() at vmspace_free+0x56 vmtotal() at vmtotal+0x3d5 sysctl_root() at sysctl_root+0xa1 userland_sysctl() at userland_sysctl+0x158 __sysctl() at __sysctl+0xaa syscall() at syscall+0x1ac Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (202, FreeBSD ELF64, __sysctl), rip = 0x800bc5a9c, rsp = 0x7fffffffdaf8, rbp = 0x7fffffffdb08 --- Fix: Unknown How-To-Repeat: Possibly running 'vmstat -m'
Responsible Changed From-To: freebsd-bugs->freebsd-fs Over to maintainer(s).
I think this order is correct. Something in ZFS must be calling pfind() or the like while holding a vnode lock. I think that is probably the "wrong" order. -- John Baldwin
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped