The following reply was made to PR kern/32535; it has been noted by GNATS.

From: Chuck Silvers <chuq@chuq.com>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, Manuel Bouyer <bouyer@antioche.eu.org>
Subject: Re: kern/32535: processes stuck on vnlock
Date: Sun, 19 Nov 2006 09:51:43 -0800

 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