syncer vnode leak because of nmount() race

Kostik Belousov kostikbel at gmail.com
Sun Jun 13 14:42:49 UTC 2010


On Fri, Jun 04, 2010 at 05:00:49PM +0200, Attilio Rao wrote:
> 2010/6/3 Jaakko Heinonen <jh at freebsd.org>:
> >
> > Hi,
> >
> > I have been playing with devfs and stress2 recently and I was able to
> > trigger a syncer vnode leak with devfs.sh. As far as I can tell it is a
> > nmount(2) (initial) mount race against update mount. The code in
> > vfs_domount() is protected with vfs_busy()/vfs_unbusy() but it doesn't
> > protect against update mounts. The protection by Giant is defeated
> > because devfs_root() may sleep due to sx_xlock(). vfs_domount() calls
> > VFS_ROOT() before allocating the syncer vnode. VI_MOUNT vnode flag
> > doesn't provide sufficient protection against update mounts either.
> 
> Thanks for this bug report.
> I think that, luckilly, it is not a very common condition to have the
> mount still in flight and get updates... :)
> However, I think that the real breakage here is that the check on
> mnt->mnt_syncer is done lockless and it is unsafe. It might really be
> protected by the mount interlock but that's tricky because
> vfs_allocate_syncvnode() sleeps. Also re-checking the condition (after
> the allocation takes place) is not too simple here.
Is it  ? I think that the patch below would fix the issue, by
syncronizing mnt_syncer by syncer mutex.

On the other hand, I prefer the jh' patch, because it seemingly disallows
parallel updates of the mount point. I believe that mp->mnt_vnodecovered
should be stable after the call to vfs_busy() succeeded.


> I found also this bug when rewriting the syncer and I resolved that by
> using a separate flag for that (in my case it was simpler and more
> beneficial actually for some other reasons, but you may do the same
> thing with a mnt_kern_flag entry).
> If you have no time I can work actively on the patch, even if I'm
> confident, luckilly, this problem is very hard to happen in the real
> life.
> 
> Additively, note that vfs_busy() here is not intended to protect
> against such situations but against unmount.
> Also, I'm very unsure about what Giant protection might bring here.
> IMHO we might probabilly remove it at all as long as all the sleeping
> point present make it completely unuseful if anything (and I don't see
> a reason why it may be needed).
> 
> > PS. vfs_unbusy(9) manual page is out of date after r184554 and IMO
> >    vfs_busy(9) manual page is misleading because it talks about
> >    synchronizing access to a mount point.
> 
> May you be more precise on what is misleading please?

diff --git a/sys/kern/vfs_mount.c b/sys/kern/vfs_mount.c
index 088d939..053bd68 100644
--- a/sys/kern/vfs_mount.c
+++ b/sys/kern/vfs_mount.c
@@ -1034,14 +1034,10 @@ vfs_domount(
 		else
 			mp->mnt_kern_flag &= ~MNTK_ASYNC;
 		MNT_IUNLOCK(mp);
-		if ((mp->mnt_flag & MNT_RDONLY) == 0) {
-			if (mp->mnt_syncer == NULL)
-				error = vfs_allocate_syncvnode(mp);
-		} else {
-			if (mp->mnt_syncer != NULL)
-				vrele(mp->mnt_syncer);
-			mp->mnt_syncer = NULL;
-		}
+		if ((mp->mnt_flag & MNT_RDONLY) == 0)
+			error = vfs_allocate_syncvnode(mp);
+		else
+			vfs_deallocate_syncvnode(mp);
 		vfs_unbusy(mp);
 		VI_LOCK(vp);
 		vp->v_iflag &= ~VI_MOUNT;
diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c
index ff6744a..6e4bb12 100644
--- a/sys/kern/vfs_subr.c
+++ b/sys/kern/vfs_subr.c
@@ -3400,12 +3400,31 @@ vfs_allocate_syncvnode(struct mount *mp)
 	/* XXX - vn_syncer_add_to_worklist() also grabs and drops sync_mtx. */
 	mtx_lock(&sync_mtx);
 	sync_vnode_count++;
+	if (mp->mnt_syncer == NULL) {
+		mp->mnt_syncer = vp;
+		vp = NULL;
+	}
 	mtx_unlock(&sync_mtx);
 	BO_UNLOCK(bo);
-	mp->mnt_syncer = vp;
+	if (vp != NULL)
+		vgone(vp);
 	return (0);
 }
 
+void
+vfs_deallocate_syncvnode(struct mount *mp)
+{
+	struct vnode *vp;
+
+	mtx_lock(&sync_mtx);
+	vp = mp->mnt_syncer;
+	if (vp != NULL)
+		mp->mnt_syncer = NULL;
+	mtx_unlock(&sync_mtx);
+	if (vp != NULL)
+		vrele(vp);
+}
+
 /*
  * Do a lazy sync of the filesystem.
  */
@@ -3484,15 +3503,16 @@ sync_reclaim(struct vop_reclaim_args *ap)
 
 	bo = &vp->v_bufobj;
 	BO_LOCK(bo);
-	vp->v_mount->mnt_syncer = NULL;
+	mtx_lock(&sync_mtx);
+	if (vp->v_mount->mnt_syncer == vp)
+		vp->v_mount->mnt_syncer = NULL;
 	if (bo->bo_flag & BO_ONWORKLST) {
-		mtx_lock(&sync_mtx);
 		LIST_REMOVE(bo, bo_synclist);
 		syncer_worklist_len--;
 		sync_vnode_count--;
-		mtx_unlock(&sync_mtx);
 		bo->bo_flag &= ~BO_ONWORKLST;
 	}
+	mtx_unlock(&sync_mtx);
 	BO_UNLOCK(bo);
 
 	return (0);
diff --git a/sys/sys/mount.h b/sys/sys/mount.h
index 20dcf64..dcff206 100644
--- a/sys/sys/mount.h
+++ b/sys/sys/mount.h
@@ -731,6 +731,7 @@ int	vfs_busy(struct mount *, int);
 int	vfs_export			 /* process mount export info */
 	    (struct mount *, struct export_args *);
 int	vfs_allocate_syncvnode(struct mount *);
+void	vfs_deallocate_syncvnode(struct mount *);
 int	vfs_donmount(struct thread *td, int fsflags, struct uio *fsoptions);
 void	vfs_getnewfsid(struct mount *);
 struct cdev *vfs_getrootfsid(struct mount *);
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20100613/adabcc54/attachment.pgp


More information about the freebsd-fs mailing list