On Mon, Dec 6, 2010 at 7:51 PM, Li Zefan <l...@cn.fujitsu.com> wrote:
> We should drop dentry before deactivating the superblock, otherwise
> we can hit this bug:
>
> BUG: Dentry f349a690{i=100,n=/} still in use (1) [unmount of btrfs loop1]
> ...
>
> Steps to reproduce the bug:
>
> # mount /dev/loop1 /mnt
> # mkdir save
> # btrfs subvolume snapshot /mnt save/snap1
> # umount /mnt
> # mount -o subvol=save/snap1 /dev/loop1 /mnt
> (crash)
>
> Reported-by: Michael Niederle <mniede...@gmx.at>
> Signed-off-by: Li Zefan <l...@cn.fujitsu.com>
> ---
> fs/btrfs/super.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> index 47bf67c..61bd79a 100644
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -685,9 +685,9 @@ static int btrfs_get_sb(struct file_system_type *fs_type,
> int flags,
> mutex_unlock(&root->d_inode->i_mutex);
>
> if (IS_ERR(new_root)) {
> + dput(root);
> deactivate_locked_super(s);
> error = PTR_ERR(new_root);
> - dput(root);
> goto error_free_subvol_name;
> }
> if (!new_root->d_inode) {
> --
this seems very reasonable to me... more than once i have wanted to be
able to mount in this way (while working out system rollback schemes
in particular; mount by name doesn't care what the ID is). what's the
possibility of a patch to mount an arbitrarily nested subvol?
btw, patch posted regarding the above:
http://www.spinics.net/lists/linux-btrfs/msg07191.html
though as author noted, needs overview by more experienced eyes.
C Anthony
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
