summaryrefslogtreecommitdiff
path: root/fs/9p
diff options
context:
space:
mode:
authorOmar Sandoval <osandov@osandov.com>2015-06-02 17:31:00 -0700
committerChris Mason <clm@fb.com>2015-06-02 19:34:33 -0700
commit64ad6c488975d7516230cf7849190a991fd615ae (patch)
tree49867e1daa030b8839ba0b8a83d7bac32452a6f0 /fs/9p
parentc65b99f046843d2455aa231747b5a07a999a9f3d (diff)
Btrfs: don't invalidate root dentry when subvolume deletion fails
Since commit bafc9b754f75 ("vfs: More precise tests in d_invalidate"), mounted subvolumes can be deleted because d_invalidate() won't fail. However, we run into problems when we attempt to delete the default subvolume while it is mounted as the root filesystem: # btrfs subvol list / ID 257 gen 306 top level 5 path rootvol ID 267 gen 334 top level 5 path snap1 # btrfs subvol get-default / ID 267 gen 334 top level 5 path snap1 # btrfs inspect-internal rootid / 267 # mount -o subvol=/ /dev/vda1 /mnt # btrfs subvol del /mnt/snap1 Delete subvolume (no-commit): '/mnt/snap1' ERROR: cannot delete '/mnt/snap1' - Operation not permitted # findmnt / findmnt: can't read /proc/mounts: No such file or directory # ls /proc # Markus reported that this same scenario simply led to a kernel oops. This happens because in btrfs_ioctl_snap_destroy(), we call d_invalidate() before we check may_destroy_subvol(), which means that we detach the submounts and drop the dentry before erroring out. Instead, we should only invalidate the dentry once the deletion has succeeded. Additionally, the shrink_dcache_sb() isn't necessary; d_invalidate() will prune the dcache for the deleted subvolume. Cc: <stable@vger.kernel.org> Fixes: bafc9b754f75 ("vfs: More precise tests in d_invalidate") Reported-by: Markus Schauler <mschauler@gmail.com> Signed-off-by: Omar Sandoval <osandov@osandov.com> Signed-off-by: Chris Mason <clm@fb.com>
Diffstat (limited to 'fs/9p')
0 files changed, 0 insertions, 0 deletions