[PATCH Coda 0/5]

[Jan Harkes]

On Thu, Jul 12, 2007 at 10:31:03AM -0400, Jan Harkes wrote:
> On Thu, Jul 12, 2007 at 01:11:03PM +0100, Robert Watson wrote:
> > When I killed venus and restarted it, then the system hung:
> ...
> >   13:49:59 starting FSDB scan (4166, 100000) (25, 75, 4)
> >   13:49:59 	2 cache files in table (0 blocks)
...
> of surprised this actually managed to wedge the system. I wonder if this
> has to do with that bit of code where we used to pass a NULL vfs mount.
> 
>     -/*  cp = make_coda_node(&ctlfid, vfsp, VCHR);
>     -    The above code seems to cause a loop in the cnode links.
>     -    I don't totally understand when it happens, it is caught
>     -    when closing down the system.
>     - */
>     -    cp = make_coda_node(&ctlfid, 0, VCHR);
>     -
>     +    cp = make_coda_node(&ctlfid, vfsp, VCHR);

And sure enough, we never released the vnode that we allocated during
the mount. And during the unmount it is marked as S_UNMOUNTING or
something similar.

Then when we remount the file system later on we get stuck, probably
waiting for the old vnode with the S_UNMOUNTING flag to disappear.

I'm not confident enough to really clean up the coda_ctlvp handling
right now. I think it can be allocated only when we actually need it,
in lookup and/or vget. But the following patch fixes the hang when I
restart venus.

Jan

--------------------------------------------------------------------
commit 6b860bfa813d1f56925eb37331c8d2dc48faf020
Author: Jan Harkes <jaharkes at freebsd.local>
Date:   Thu Jul 12 14:34:51 2007 -0400

    Make sure we release the control vnode.
    
    We allocate coda_ctlvp when /coda is mounted, but never release it.
    During the unmount this vnode was marked as UNMOUNTING and when venus
    is started a second time the system would hang, possibly waiting for
    the old vnode to disappear.
    
    So now we call vrele on the control vnode when file system is unmounted
    to drop the reference we got during the mount. I'm pretty sure it is
    also necessary to not skip the handling in coda_inactive for the control
    vnode, it seems like that is the place we actually get rid of the vnode
    once the refcount has dropped to 0.

diff --git a/coda_vfsops.c b/coda_vfsops.c
index df6f3f9..db7c11e 100644
--- a/coda_vfsops.c
+++ b/coda_vfsops.c
@@ -227,6 +227,7 @@ coda_unmount(vfsp, mntflags, td)
 	printf("coda_unmount: ROOT: vp %p, cp %p\n", mi->mi_rootvp, VTOC(mi->mi_rootvp));
 #endif
 	vrele(mi->mi_rootvp);
+	vrele(coda_ctlvp);
 	active = coda_kill(vfsp, NOT_DOWNCALL);
 	ASSERT_VOP_LOCKED(mi->mi_rootvp, "coda_unmount");
 	mi->mi_rootvp->v_vflag &= ~VV_ROOT;
diff --git a/coda_vnops.c b/coda_vnops.c
index 3639779..a4d7047 100644
--- a/coda_vnops.c
+++ b/coda_vnops.c
@@ -745,11 +745,6 @@ coda_inactive(struct vop_inactive_args *ap)
     /* We don't need to send inactive to venus - DCS */
     MARK_ENTRY(CODA_INACTIVE_STATS);
 
-    if (IS_CTL_VP(vp)) {
-	MARK_INT_SAT(CODA_INACTIVE_STATS);
-	return 0;
-    }
-
     CODADEBUG(CODA_INACTIVE, myprintf(("in inactive, %s, vfsp %p\n",
 				  coda_f2s(&cp->c_fid), vp->v_mount));)