On Thursday 04 September 2008 03:41:19 am David Xu wrote: > I saw so many LORs like following, I think this is a false reporting > because the interlock is released by lockmgr whether the thread is > blocked or not, shouldn't WITNESS_CHECKORDER bypass this interlock ? I have a patch to fix this, I will commit it soon. > lock order reversal: (sleepable after non-sleepable) > 1st 0xc48d728c vnode interlock (vnode interlock) _at_ > fs/devfs/devfs_vnops.c:286 > 2nd 0xc48d7270 devfs (devfs) _at_ kern/vfs_subr.c:2051 > KDB: stack backtrace: > db_trace_self_wrapper(c0b6d1e1,c4199a2c,c07f1d35,4,c0b68bf7,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(4,c0b68bf7,c0de8a58,c44768d0,c4199b64,...) at > kdb_backtrace+0x29 > _witness_debugger(c0b6fa7b,c48d6000,c0b761c4,c44768d0,c0b7679d,...) at > _witness_debugger+0x25 > witness_checkorder(c48d6000,1,c0b76794,174,c0b68bf7,...) at > witness_checkorder+0x7c9 > __lockmgr_args(c48d6000,200100,c48d601c,0,0,...) at __lockmgr_args+0x230 > vfs_busy(c48d6000,200,0,1,c44c6d20,...) at vfs_busy+0x1bc > vfs_mount_alloc(0,c0c3bae0,c0b7653a,c44b1400,c0831580,...) at > vfs_mount_alloc+0x74 > vfs_mountroot(c0caef30,4,c0b64bc9,264,0,...) at vfs_mountroot+0x272 > start_init(0,c4199d38,c0b66578,322,c44c4d0c,...) at start_init+0x65 > fork_exit(c077a040,0,c4199d38) at fork_exit+0xb8 > > > David Xu > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" -- John BaldwinReceived on Mon Sep 08 2008 - 19:31:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:35 UTC