On Wed 14-01-15 10:42:38, Christoph Hellwig wrote:
> bdi_destroy already does all the work, and if we delay freeing the
> anon bdev we can get away with just that single call.
  Looks good. You can add:
Reviewed-by: Jan Kara <[email protected]>

                                                                Honza

> 
> Signed-off-by: Christoph Hellwig <[email protected]>
> ---
>  fs/ceph/super.c | 18 ++++++------------
>  1 file changed, 6 insertions(+), 12 deletions(-)
> 
> diff --git a/fs/ceph/super.c b/fs/ceph/super.c
> index 50f06cd..e350cc1 100644
> --- a/fs/ceph/super.c
> +++ b/fs/ceph/super.c
> @@ -40,17 +40,6 @@ static void ceph_put_super(struct super_block *s)
>  
>       dout("put_super\n");
>       ceph_mdsc_close_sessions(fsc->mdsc);
> -
> -     /*
> -      * ensure we release the bdi before put_anon_super releases
> -      * the device name.
> -      */
> -     if (s->s_bdi == &fsc->backing_dev_info) {
> -             bdi_unregister(&fsc->backing_dev_info);
> -             s->s_bdi = NULL;
> -     }
> -
> -     return;
>  }
>  
>  static int ceph_statfs(struct dentry *dentry, struct kstatfs *buf)
> @@ -1002,11 +991,16 @@ out_final:
>  static void ceph_kill_sb(struct super_block *s)
>  {
>       struct ceph_fs_client *fsc = ceph_sb_to_client(s);
> +     dev_t dev = s->s_dev;
> +
>       dout("kill_sb %p\n", s);
> +
>       ceph_mdsc_pre_umount(fsc->mdsc);
> -     kill_anon_super(s);    /* will call put_super after sb is r/o */
> +     generic_shutdown_super(s);
>       ceph_mdsc_destroy(fsc);
> +
>       destroy_fs_client(fsc);
> +     free_anon_bdev(dev);
>  }
>  
>  static struct file_system_type ceph_fs_type = {
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to [email protected]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
Jan Kara <[email protected]>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to