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