From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 11:09:17 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D93716A419; Thu, 7 Feb 2008 11:09:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id E6FE813C4F0; Thu, 7 Feb 2008 11:09:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JN4cs-0008fr-7t; Thu, 07 Feb 2008 13:09:15 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id m17B8gf4045945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Feb 2008 13:08:42 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m17B928p026455; Thu, 7 Feb 2008 13:09:02 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m17B91j9026454; Thu, 7 Feb 2008 13:09:01 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 7 Feb 2008 13:09:01 +0200 From: Kostik Belousov To: Attilio Rao Message-ID: <20080207110901.GZ57756@deviant.kiev.zoral.com.ua> References: <20080207045015.GW57756@deviant.kiev.zoral.com.ua> <3bbf2fe10802070216idd5206ey7a66c0873311e66c@mail.gmail.com> <20080207104354.GY57756@deviant.kiev.zoral.com.ua> <3bbf2fe10802070304r29cb8d2u1210fe285c917424@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4TGiQDXW1h0LgEzD" Content-Disposition: inline In-Reply-To: <3bbf2fe10802070304r29cb8d2u1210fe285c917424@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Scanner-Signature: e860fde63604f368aea63056fc3ed89d X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 2189 [Feb 07 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: 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: Thu, 07 Feb 2008 11:09:17 -0000 --4TGiQDXW1h0LgEzD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 bo= x: > > > > > > > > > > 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/sy= s/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 othe= r 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 ? >=20 > 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. --4TGiQDXW1h0LgEzD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkeq5s0ACgkQC3+MBN1Mb4hXpQCdHGT+wwQ4eybxevwH0Nki8pAA jTwAnjIu0wzbsMlnGwHfh3juyTfb/CnN =KBi1 -----END PGP SIGNATURE----- --4TGiQDXW1h0LgEzD--