nfsd hung on ufs vnode lock

[John Baldwin]

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