syncer vnode leak because of nmount() race

[Attilio Rao]

I think that the patch looks good.
Did you test it?
Otherwise you could ask to gianni@ to test it out.

Thanks,
Attilio


2010/6/13 Kostik Belousov <kostikbel at gmail.com>:
> 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 *);
>



-- 
Peace can only be achieved by understanding - A. Einstein