From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 12:21:11 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 8F10116A419 for ; Thu, 7 Feb 2008 12:21:11 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id F422413C461 for ; Thu, 7 Feb 2008 12:21:10 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so970003uge.37 for ; Thu, 07 Feb 2008 04:21:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=/S3xS6/+CThx7pADuBMxyhrs15AxTODQevRagpYm86c=; b=n9ZS8OcpxEUWzbdWe3U9r0pYQsDOykGlyRjZNhtIK2/oI4s9CSmwbuqGdPsif+gWoe/BSSI0XBW7/6OLGXMBbC/0X1rx3MtlzQwv7DR9e9yemVBLcS0zynyfm45Ido07MFOWFigatDZbcSkiHHa3qQPgePHPrL8hM0E0esxje5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=IfvJFzwOih9y2D7X/mm+68+NOeBdB6EW+/T7POlWt3V+mTjrJiyV+Ei3Xuuk4GhbJzw89LStOW+V0HZCbE/IUsHvCdQcD5R022+FWvM0x872ahAb/CPb3WMS/j6vft0oEWNZ0p2cnZMLKBJ1ay6YOdLOhyApwMFzjYhIRMTYvYQ= Received: by 10.67.30.6 with SMTP id h6mr3977825ugj.6.1202386869430; Thu, 07 Feb 2008 04:21:09 -0800 (PST) Received: by 10.86.28.19 with HTTP; Thu, 7 Feb 2008 04:21:09 -0800 (PST) Message-ID: <3bbf2fe10802070421m3a3152a3m6c9aa67d649107e4@mail.gmail.com> Date: Thu, 7 Feb 2008 13:21:09 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Kostik Belousov" In-Reply-To: <20080207110901.GZ57756@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080207045015.GW57756@deviant.kiev.zoral.com.ua> <3bbf2fe10802070216idd5206ey7a66c0873311e66c@mail.gmail.com> <20080207104354.GY57756@deviant.kiev.zoral.com.ua> <3bbf2fe10802070304r29cb8d2u1210fe285c917424@mail.gmail.com> <20080207110901.GZ57756@deviant.kiev.zoral.com.ua> X-Google-Sender-Auth: 9ae8e4d4e47c2aa3 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 12:21:11 -0000 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? Really I think this will need some witness tweaking. After all a mechanism for ignoring specific LOR (happening at specified file-line) is not a bad idea. Attilio -- Peace can only be achieved by understanding - A. Einstein