Re: find stuck in state "clock"

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:
:Simon 'corecode' Schubert wrote:
:> Conclusion:
:> [*] The fact that the namecache entry is locked, doesn't lead to the 
:> deadlock, but it is the reason that dozens of find(1)s lock on /dev/ttyp5.
:
:Why do we keep the namecache entry locked in e.g. kern_chown?  We just 
:need the vnode (nlookup) and not the namecache, or am I wrong?
:
:cheers
:   simon

    The namecache entry is locked for all namespace operations.  That isn't
    the problem... it's the fact that the device close() is blocked while
    holding the vnode locked that is the real problem.

    You could try this patch temporarily.  I probably have to do something
    a bit more complex to handle all the race conditions but it should work
    for now.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>

Index: spec_vnops.c
===================================================================
RCS file: /cvs/src/sys/vfs/specfs/spec_vnops.c,v
retrieving revision 1.26
diff -u -r1.26 spec_vnops.c
--- spec_vnops.c	3 Aug 2005 16:36:33 -0000	1.26
+++ spec_vnops.c	29 Aug 2005 04:55:57 -0000
@@ -573,7 +573,9 @@
 	if (dev && ((vp->v_flag & VRECLAIMED) ||
 	    (dev_dflags(dev) & D_TRACKCLOSE) ||
 	    (vcount(vp) <= 1 && vp->v_opencount == 1))) {
+		VOP_UNLOCK(vp, 0, ap->a_td);
 		error = dev_dclose(dev, ap->a_fflag, S_IFCHR, ap->a_td);
+		vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, ap->a_td);
 	} else {
 		error = 0;
 	}