From owner-freebsd-stable@FreeBSD.ORG Tue Feb 1 14:53:18 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9A8B10657EA for ; Tue, 1 Feb 2011 14:53:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BB0CB8FC0A for ; Tue, 1 Feb 2011 14:53:17 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7340B46B17; Tue, 1 Feb 2011 09:53:17 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 416FD8A02B; Tue, 1 Feb 2011 09:53:16 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 1 Feb 2011 09:50:29 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <201101311200.29897.jhb@freebsd.org> <20110131222924.GF7923@deterlab.net> In-Reply-To: <20110131222924.GF7923@deterlab.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102010950.29346.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 01 Feb 2011 09:53:16 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: John Hickey Subject: Re: nfsd hung on ufs vnode lock X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 14:53:18 -0000 On Monday, January 31, 2011 5:29:24 pm John Hickey wrote: > On Mon, Jan 31, 2011 at 12:00:29PM -0500, John Baldwin wrote: > (kgdb) vprint vp > 0xd417633c: tag none, type VBAD > usecount 0, writecount 0, refcount 1 mountedhere 0x0 > flags (VI_DOOMED) > lock type ufs: UNLOCKED with 1 pending > (kgdb) Ok, this looks exactly like the bug I fixed in the two revisions below. > > There's a chance though you are tripping over the bug fixed by these two > > changes: > > I should be able to sync up with 7.4 without much pain in a few days. > > > Author: jhb > > Date: Fri Jul 16 20:23:24 2010 > > New Revision: 210173 > > URL: http://svn.freebsd.org/changeset/base/210173 > > > > Log: > > When the MNTK_EXTENDED_SHARED mount option was added, some filesystems were > > changed to defer the setting of VN_LOCK_ASHARE() (which clears LK_NOSHARE > > in the vnode lock's flags) until after they had determined if the vnode was > > a FIFO. This occurs after the vnode has been inserted into a VFS hash or > > some similar table, so it is possible for another thread to find this vnode > > via vget() on an i-node number and block on the vnode lock. If the lockmgr > > interlock (vnode interlock for vnode locks) is not held when clearing the > > LK_NOSHARE flag, then the lk_flags field can be clobbered. As a result > > the thread blocked on the vnode lock may never get woken up. Fix this by > > holding the vnode interlock while modifying the lock flags in this case. > > > > The softupdates code also toggles LK_NOSHARE in one function to close a > > race with snapshots. Fix this code to grab the interlock while fiddling > > with lk_flags. > > > > Author: jhb > > Date: Fri Aug 20 20:58:57 2010 > > New Revision: 211533 > > URL: http://svn.freebsd.org/changeset/base/211533 > > > > Log: > > Revert 210173 as it did not properly fix the bug. It assumed that the > > VI_LOCK() for a given vnode was used as the internal interlock for that > > vnode's v_lock lockmgr lock. This is not the case. Instead, add dedicated > > routines to toggle the LK_NOSHARE and LK_CANRECURSE flags. These routines > > lock the lockmgr lock's internal interlock to synchronize the updates to > > the flags member with other threads attempting to acquire the lock. The > > VN_LOCK_A*() macros now invoke these routines, and the softupdates code > > uses these routines to temporarly enable recursion on buffer locks. > > > > Reviewed by: kib -- John Baldwin