- Reorder calls to vrele() after calls to vput() when the vrele is a

   directory.  vrele() may lock the passed vnode, which in these cases would
   give an invalid lock order of child -> parent.  These situations are
   deadlock prone although do not typically deadlock because the vrele
   is typically not releasing the last reference to the vnode.  Users of
   vrele must consider it as a call to vn_lock() and order it appropriately.

MFC After: 	1 week
Sponsored by:	Isilon Systems, Inc.
Tested by:	kkenn

1 files changed, 9 insertions, 12 deletions

diff --git a/sys/fs/coda/coda_vnops.c b/sys/fs/coda/coda_vnops.c
index 94d95d9..75de19f 100644
--- a/sys/fs/coda/coda_vnops.c
+++ b/sys/fs/coda/coda_vnops.c
@@ -1289,21 +1289,18 @@ coda_rename(struct vop_rename_args *ap)
     /* XXX - do we need to call cache pureg on the moved vnode? */
     cache_purge(ap->a_fvp);
 
-    /* It seems to be incumbent on us to drop locks on all four vnodes */
-    /* From-vnodes are not locked, only ref'd.  To-vnodes are locked. */
-
-    vrele(ap->a_fvp);
+    /* Release parents first, then children. */
     vrele(odvp);
-
     if (ap->a_tvp) {
-	if (ap->a_tvp == ndvp) {
-	    vrele(ap->a_tvp);
-	} else {
-	    vput(ap->a_tvp);
-	}
-    }
+	if (ap->a_tvp == ndvp)
+	    vrele(ndvp);
+	else
+	    vput(ndvp);
+	vput(ap->a_tvp);
+    } else
+	vput(ndvp);
+    vrele(ap->a_fvp);
 
-    vput(ndvp);
     return(error);
 }