Subject: Re: problems with -current hangs/panics
To: None <dave@dogwood.com>
From: John Kohl <jtk@kolvir.arlington.ma.us>
List: current-users
Date: 06/20/1996 23:03:32
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;