I know of at least one more bug in nullfs handling which can cause
deadlocks between processes.  Here's a potential patch (but given my
earlier comments in this place, I don't think that either with or
without the patch will always work.  with this patch applied has been
less buggy for me recently):

Index: null_vnops.c
===================================================================
RCS file: /u4/cvsroot/src/sys/miscfs/nullfs/null_vnops.c,v
retrieving revision 1.1.1.3
retrieving revision 1.14
diff -c -r1.1.1.3 -r1.14
*** null_vnops.c	1996/05/12 19:42:07	1.1.1.3
--- null_vnops.c	1996/06/13 02:30:56	1.14
***************
*** 524,536 ****
  
  	nn = VTONULL(vp);
  
! 	if ((nn->null_flags & NULL_LLOCK) == 0 &&
! 	    (vp->v_usecount != 0)) {
  		/*
  		 * only lock underlying node if we haven't locked it yet
  		 * for null ops, and our refcount is nonzero.  If usecount
  		 * is zero, we are probably being reclaimed so we need to
  		 * keep our hands off the lower node.
  		 */
  		VOP_LOCK(nn->null_lowervp);
  		nn->null_flags |= NULL_LLOCK;
--- 524,538 ----
  
  	nn = VTONULL(vp);
  
! 	if ((nn->null_flags & NULL_LLOCK) == 0 /*&&
! 	    (vp->v_usecount != 0)*/) {
  		/*
  		 * only lock underlying node if we haven't locked it yet
  		 * for null ops, and our refcount is nonzero.  If usecount
  		 * is zero, we are probably being reclaimed so we need to
  		 * keep our hands off the lower node.
+ 		 * XXX we can't just leave it alone, though--otherwise
+ 		 * there are latent locking problems in our call-ees.
  		 */
  		VOP_LOCK(nn->null_lowervp);
  		nn->null_flags |= NULL_LLOCK;