Subject: Re: kern/32535: processes stuck on vnlock
To: None <gnats-bugs@NetBSD.org>
From: Chuck Silvers <chuq@chuq.com>
List: netbsd-bugs
Date: 11/19/2006 09:51:43
On Tue, Sep 26, 2006 at 01:35:02AM +0000, Bill Studenmund wrote:
>  2) We could re-work lookup() so that we don't release the directory lock
>  if we're locking the child and we instead call vput(). I think this is the
>  best option as it gets rid of the real problem. I'll look into it, but
>  if someone else wants to look into this, please do! I'm not sure how
>  quickly I can look at it.


I've put a diff that implements this at
ftp://ftp.netbsd.org/pub/NetBSD/misc/chs/lookup/diff.20061119


details:
 - LOCKPARENT is no longer relevant for lookup(), relookup() or VOP_LOOKUP().
   these now always return the parent vnode locked.  namei() works as before.
   lookup() and various other paths no longer acquire vnode locks in the
   wrong order via vrele().  this should fix PR 32535.
 - the above allows us to get rid of PDIRUNLOCK.
 - also get rid of WANTPARENT (just use LOCKPARENT and unlock it).

more things fixed in this patch that I found while testing the above:
 - remove an assumption in layer_node_find() that all file systems implement
   a recursive VOP_LOCK() (unionfs doesn't).
 - require that all file systems supply vfs_vptofh and vfs_fhtovp routines.
   fill in eopnotsupp() for file systems that don't support being exported
   and remove the checks for NULL.  (layerfs calls these without checking.)
 - in union_lookup1(), don't change refcounts in the ISDOTDOT case, just
   adjust which vnode is locked.  fixes PR 33374.
 - apply fixes for ufs_rename() from ufs_vnops.c rev. 1.61 to ext2fs_rename().


-Chuck