Date: Tue, 17 Jul 2007 14:36:51 -0400 From: Jan Harkes <jaharkes@cs.cmu.edu> To: freebsd-fs@freebsd.org Subject: Re: [PATCH Coda 0/5] Message-ID: <20070717183651.GA16599@delft.aura.cs.cmu.edu> In-Reply-To: <20070712143103.GR5824@delft.aura.cs.cmu.edu> References: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> <1184090521301-git-send-email-jaharkes@cs.cmu.edu> <20070711223527.S97304@fledge.watson.org> <20070711223517.GH5824@delft.aura.cs.cmu.edu> <4695989B.7020200@freebsd.org> <20070712034033.GO5824@delft.aura.cs.cmu.edu> <20070712124134.G27319@fledge.watson.org> <20070712143103.GR5824@delft.aura.cs.cmu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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));)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070717183651.GA16599>