From owner-freebsd-current@FreeBSD.ORG Wed Feb 13 18:28:35 2008 Return-Path: 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 0274316A41A; Wed, 13 Feb 2008 18:28:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 4C32813C447; Wed, 13 Feb 2008 18:28:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8s) with ESMTP id 231815164-1834499 for multiple; Wed, 13 Feb 2008 13:26:31 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m1DISMai076706; Wed, 13 Feb 2008 13:28:25 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 13 Feb 2008 11:38:27 -0500 User-Agent: KMail/1.9.7 References: <20080207125252.GC57756@deviant.kiev.zoral.com.ua> <3bbf2fe10802070611v6c7714b5y18bef10d586944c4@mail.gmail.com> In-Reply-To: <3bbf2fe10802070611v6c7714b5y18bef10d586944c4@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802131138.27471.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 13 Feb 2008 13:28:26 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5799/Wed Feb 13 10:15:22 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Attilio Rao , Kostik Belousov , Marcel Moolenaar , current@freebsd.org Subject: Re: Old LOR between devfs & devfsmount resurfacing? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2008 18:28:35 -0000 On Thursday 07 February 2008 09:11:46 am Attilio Rao wrote: > 2008/2/7, Kostik Belousov : > > On Thu, Feb 07, 2008 at 01:21:09PM +0100, Attilio Rao wrote: > > > 2008/2/7, Kostik Belousov : > > > > On Thu, Feb 07, 2008 at 12:04:28PM +0100, Attilio Rao wrote: > > > > > 2008/2/7, Kostik Belousov : > > > > > > On Thu, Feb 07, 2008 at 11:16:08AM +0100, Attilio Rao wrote: > > > > > > > 2008/2/7, Kostik Belousov : > > > > > > > > On Wed, Feb 06, 2008 at 11:11:06AM -0800, Marcel Moolenaar wrote: > > > > > > > > > All, > > > > > > > > > > > > > > > > > > I just ran into the following LOR after upgrading my PowerPC box: > > > > > > > > > > > > > > > > > > lock order reversal: > > > > > > > > > 1st 0xdbee94 devfs (devfs) @ /nfs/freebsd/8.x/src/sys/kern/ > > > > > > > > > vfs_subr.c:2061 > > > > > > > > > 2nd 0xdfb014 devfsmount (devfsmount) @ /nfs/freebsd/8.x/src/sys/fs/ > > > > > > > > > devfs/devfs_vnops.c:201 > > > > > > > > > KDB: stack backtrace: > > > > > > > > > 0xdc0febc8: at kdb_backtrace+0x4c > > > > > > > > > 0xdc0febd8: at witness_checkorder+0x704 > > > > > > > > > 0xdc0fec28: at _sx_xlock+0x8c > > > > > > > > > 0xdc0fec48: at devfs_allocv+0x138 > > > > > > > > > 0xdc0fec88: at devfs_root+0x5c > > > > > > > > > 0xdc0fecb8: at set_rootvnode+0x44 > > > > > > > > > 0xdc0fece8: at vfs_mountroot+0x344 > > > > > > > > > 0xdc0fed48: at start_init+0x88 > > > > > > > > > 0xdc0feda8: at fork_exit+0xb4 > > > > > > > > > 0xdc0fedc8: at fork_trampoline+0xc > > > > > > > > > KDB: enter: witness_checkorder > > > > > > > > > [thread pid 1 tid 100001 ] > > > > > > > > > Stopped at 0x28ee68: addi r0, r0, 0x0 > > > > > > > > > > > > > > > > > > It seems that this is a LOR reported in 2006 and fixed > > > > > > > > > in 2006 as well. Do other people see this too, or should > > > > > > > > > I suspect my sources? > > > > > > > > > > > > > > > > > > > > > > > > I believe this is a false positive, caused by the way the witness works. > > > > > > > > Attilio recently added the witness support for the lockmgr, that caused > > > > > > > > this and at least two more LORs to be printed on startup. > > > > > > > > > > > > > > > > Correct lock order is devfs vnode -> devfs mount sx lock. When > > > > > > > > allocating new devfs vnode, see devfs_allocv(), the newly created > > > > > > > > vnode is locked while devfs mount lock already held (see line 250 of > > > > > > > > fs/devfs/devfs_vnops.c). Nonetheless, this cannot cause deadlock since > > > > > > > > no other thread can find the new vnode, and thus perform the other lock > > > > > > > > order for this vnode lock. > > > > > > > > > > > > > > > > The fix is to shut the witness in this particular case. Attilio, how to > > > > > > > > do this ? > > > > > > > > > > > > > > Just add LK_NOWITNESS for one of the lock involved in the lockinit(). > > > > > > > > > > > > > > > > > > Then, we loss the useful reports of the actual LORs later, isn't it ? > > > > > > > > > > Another solution would be to rewamp BLESSING option which allow to > > > > > 'bless' some LORs. > > > > > jhb and me, btw, didn't want to enable it because it could lead some > > > > > less experienced developer to hide LORs under this label and this is > > > > > something we want to avoid. > > > > > > > > > > > > This LOR shall not be ignored globally. When real, it caused the easily > > > > reproducable lockup of the machine. > > > > > > > > It would be better to introduce some lockmgr flag to ignore _this_ locking. > > > > > > flag to pass where? > > To the lockmgr itself at the point of aquisition, like > > lockmgr(&lk, LK_EXCLUSIVE | LK_INTERLOCK | LK_NOWARN, &interlk, ...); > > No, I really want a general WITNESS support for this (as I also think > that having something more fine grained than BLESSING will break all > concerns jhb and me are considering now). > A simple way to do it would mean hard-coding file and line in a > witness table. While file is ok, line makes trouble so we should find > an alternative way to do this. Otherwise we can consider skiping > checks for a whole function, this should be not so difficult to > achive. > > I need to think more about this. I think allowing a flag is fine, just as you can specify MTX_QUIET to quiet KTR logs in specific mtx_lock() instances. You would specify LK_NOWITNESS or some such and have it not do a witness_checkorder() in that case. -- John Baldwin