On Sat Jul 07 2007 at 16:59:09 +0300, Antti Kantee wrote:
> With what you're suggesting, sounds easier that we simply don't drain the
> lock at all.  Reference counting of vnodes, VXLOCK, taking an exclusive
> lock in vclean() etc. should take care of the effects of LK_DRAIN?
> 
> I still don't like it, though, but I think it's the best of the bad
> options we have.

Yup, that appears pretty good per simple testing:

Index: vfs_subr.c
===================================================================
RCS file: /cvsroot/src/sys/kern/vfs_subr.c,v
retrieving revision 1.288
diff -p -u -r1.288 vfs_subr.c
--- vfs_subr.c	5 Jun 2007 12:31:31 -0000	1.288
+++ vfs_subr.c	7 Jul 2007 14:27:01 -0000
@@ -1522,12 +1522,11 @@ vclean(struct vnode *vp, int flags, stru
 
 	/*
 	 * Even if the count is zero, the VOP_INACTIVE routine may still
-	 * have the object locked while it cleans it out. The VOP_LOCK
-	 * ensures that the VOP_INACTIVE routine is done with its work.
-	 * For active vnodes, it ensures that no other activity can
+	 * have the object locked while it cleans it out.  For
+	 * active vnodes, it ensures that no other activity can
 	 * occur while the underlying object is being cleaned out.
 	 */
-	VOP_LOCK(vp, LK_DRAIN | LK_INTERLOCK);
+	VOP_LOCK(vp, LK_EXCLUSIVE | LK_INTERLOCK);
 
 	/*
 	 * Clean out any cached data associated with the vnode.
@@ -1649,6 +1648,7 @@ vclean(struct vnode *vp, int flags, stru
 	 */
 	vp->v_op = dead_vnodeop_p;
 	vp->v_tag = VT_NON;
+	vp->v_vnlock = NULL;
 	simple_lock(&vp->v_interlock);
 	VN_KNOTE(vp, NOTE_REVOKE);	/* FreeBSD has this in vn_pollgone() */
 	vp->v_flag &= ~(VXLOCK|VLOCKSWORK);

-- 
Antti Kantee <pooka@iki.fi>                     Of course he runs NetBSD
http://www.iki.fi/pooka/                          http://www.NetBSD.org/
    "la qualité la plus indispensable du cuisinier est l'exactitude"