Seeing lock order reversal

From: Alex Goncharov <alex-goncharov_at_comcast.net>
Date: Mon, 17 Mar 2008 19:48:45 -0400
[ Sorry if this is old news or not useful ]

I am trying to source-upgrade one of my 7.0 systems to 8.0-CURRENT.

In the following, when I say "build", it means "csup and build right
away".

The very first 8.0 build (this morning) gave me the kernel that didn't
boot.  Built it again, finishing about 15 minutes ago.  This one
booted all right but I see this in `/var/log/messages':

================================================================================
WARNING: WITNESS option enabled, expect reduced performance.
lock order reversal:
1st 0xc4093e28 devfs (devfs) _at_ /mnt/wdx/freebsd/8.0/usr/src/sys/kern/vfs_subr.c:2064
2nd 0xc4172b54 devfsmount (devfsmount) _at_ /mnt/wdx/freebsd/8.0/usr/src/sys/fs/devfs/devfs_vnops.c:201
KDB: stack backtrace:
db_trace_self_wrapper(c0af5d71,e2888bbc,c07a70de,c0af8353,c4172b54,...) at db_trace_self_wrapper+0x26
kdb_backtrace(c0af8353,c4172b54,c0ae90df,c0ae90df,c0ae9120,...) at kdb_backtrace+0x29
witness_checkorder(c4172b54,9,c0ae9120,c9,c7,...) at witness_checkorder+0x6de
_sx_xlock(c4172b54,0,c0ae9120,c9,c4172b54,...) at _sx_xlock+0x7d
devfs_allocv(c415db80,c4174000,e2888c28,c3e1ecc0,c0afe288,...) at devfs_allocv+0x144
devfs_root(c4174000,2,c0c67378,c3e1ecc0,ca,...) at devfs_root+0x51
set_rootvnode(c0c67360,0,c0afe288,5f4,c07e4aa0,...) at set_rootvnode+0x2b
vfs_mountroot(c0c15270,4,c0aed8e7,264,0,...) at vfs_mountroot+0x356
start_init(0,e2888d38,c0aef370,30c,c3e1ccd0,...) at start_init+0x65
fork_exit(c0737740,0,e2888d38) at fork_exit+0xb8
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xe2888d70, ebp = 0 ---
Trying to mount root from ufs:/dev/ad4s1a
lock order reversal:
1st 0xc40939e8 ufs (ufs) _at_ /mnt/wdx/freebsd/8.0/usr/src/sys/kern/vfs_subr.c:2064
2nd 0xc4174000 vfslock (vfslock) _at_ /mnt/wdx/freebsd/8.0/usr/src/sys/kern/vfs_subr.c:364
KDB: stack backtrace:
db_trace_self_wrapper(c0af5d71,e28889d8,c07a70de,c0af8353,c4174000,...) at db_trace_self_wrapper+0x26
kdb_backtrace(c0af8353,c4174000,c0afe39a,c0afe39a,c0afe937,...) at kdb_backtrace+0x29
witness_checkorder(c4174000,1,c0afe937,16c,e2888a18,...) at witness_checkorder+0x6de
_lockmgr_args(c4174000,20001,c4174030,0,ffffffff,...) at _lockmgr_args+0x1d5
vfs_busy(c4174000,0,0,c3e1ecc0,e2888b58,...) at vfs_busy+0x1b0
lookup(e2888b44,c0afe022,c6,bf,c3dee22c,...) at lookup+0x7bf
namei(e2888b44,c4174030,1c1,c0afe288,e2888b54,...) at namei+0x34b
kern_unlink(c3e1ecc0,c0afe6d9,1,62f,0,...) at kern_unlink+0x40
vfs_mountroot_try(c0afe893,c0aec557,c0ae4ade,1,c07e4aa0,...) at vfs_mountroot_try+0x470
vfs_mountroot(c0c15270,4,c0aed8e7,264,0,...) at vfs_mountroot+0x418
start_init(0,e2888d38,c0aef370,30c,c3e1ccd0,...) at start_init+0x65
fork_exit(c0737740,0,e2888d38) at fork_exit+0xb8
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xe2888d70, ebp = 0 ---
lock order reversal:
1st 0xc3e22044 user map (user map) _at_ /mnt/wdx/freebsd/8.0/usr/src/sys/vm/vm_map.c:3111
2nd 0xc40937c8 ufs (ufs) _at_ /mnt/wdx/freebsd/8.0/usr/src/sys/kern/vfs_subr.c:2064
KDB: stack backtrace:
db_trace_self_wrapper(c0af5d71,e28889c4,c07a70de,c0af8353,c40937c8,...) at db_trace_self_wrapper+0x26
kdb_backtrace(c0af8353,c40937c8,c0aece96,c0aece96,c0afe937,...) at kdb_backtrace+0x29
witness_checkorder(c40937c8,1,c0afe937,810,e28889e8,...) at witness_checkorder+0x6de
_lockmgr_args(c40937c8,30041,c40937f8,0,ffffffff,...) at _lockmgr_args+0x1d5
ffs_lock(e2888a78,c075fc3d,c0c20554,30041,c4093770,...) at ffs_lock+0xa3
VOP_LOCK1_APV(c0bcbec0,e2888a78,c0aec555,3,c40937f8,...) at VOP_LOCK1_APV+0xa5
_vn_lock(c4093770,30041,c0afe937,810,0,...) at _vn_lock+0xf7
vget(c4093770,30041,c3e1ecc0,4a9,c1460600,...) at vget+0x10b
vnode_pager_lock(c1460480,0,c0b157d5,127,e2888be8,...) at vnode_pager_lock+0x1ad
vm_fault(c3e22000,80cf000,2,8,80cf340,...) at vm_fault+0x1df
trap_pfault(5,0,c0b23bd2,2c4,c3e1ccd0,...) at trap_pfault+0x118
trap(e2888d38) at trap+0x259
calltrap() at calltrap+0x6
--- trap 0xc, eip = 0x80480e5, esp = 0xbfbfeef0, ebp = 0xbfbfef10 ---
--------------------------------------------------------------------------------=

Is this information of any use?

I've seen a fair number of messages about LOR on some freebsd lists
but was not paying attention -- maybe what I see has already been
covered.  But in case the above is useful, I can try to provide more
information.

Thanks,

-- Alex -- alex-goncharov_at_comcast.net --
Received on Mon Mar 17 2008 - 23:04:48 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:29 UTC