From owner-freebsd-current@FreeBSD.ORG  Thu Sep  4 07:39:36 2008
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id C458C1065672
	for <freebsd-current@freebsd.org>; Thu,  4 Sep 2008 07:39:36 +0000 (UTC)
	(envelope-from davidxu@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
	[IPv6:2001:4f8:fff6::28])
	by mx1.freebsd.org (Postfix) with ESMTP id B3C678FC21
	for <freebsd-current@freebsd.org>; Thu,  4 Sep 2008 07:39:36 +0000 (UTC)
	(envelope-from davidxu@freebsd.org)
Received: from apple.my.domain (root@localhost [127.0.0.1])
	by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m847dZfR077308
	for <freebsd-current@freebsd.org>; Thu, 4 Sep 2008 07:39:36 GMT
	(envelope-from davidxu@freebsd.org)
Message-ID: <48BF911F.4000600@freebsd.org>
Date: Thu, 04 Sep 2008 15:41:19 +0800
From: David Xu <davidxu@freebsd.org>
User-Agent: Thunderbird 2.0.0.9 (X11/20080612)
MIME-Version: 1.0
To: FreeBSD Current <freebsd-current@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: lockmgr_args, lock order reversal: (sleepable after non-sleepable)
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Sep 2008 07:39:36 -0000

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 ?


lock order reversal: (sleepable after non-sleepable)
  1st 0xc48d728c vnode interlock (vnode interlock) @ 
fs/devfs/devfs_vnops.c:286
  2nd 0xc48d7270 devfs (devfs) @ 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