diff options
author | Filipe Manana <fdmanana@suse.com> | 2014-11-26 15:28:50 +0000 |
---|---|---|
committer | Chris Mason <clm@fb.com> | 2014-12-02 18:19:17 -0800 |
commit | 292cbd51ecf85d73195a3e3193937fa770f6ea71 (patch) | |
tree | ef651a477536ba72b8cbdf951b823135ca5b3ee4 /fs/btrfs/super.c | |
parent | 9ea24bbe17a29f937e7f48e4b15fd52e89e9d386 (diff) | |
download | linux-292cbd51ecf85d73195a3e3193937fa770f6ea71.tar.gz linux-292cbd51ecf85d73195a3e3193937fa770f6ea71.tar.bz2 linux-292cbd51ecf85d73195a3e3193937fa770f6ea71.zip |
Btrfs: fix invalid block group rbtree access after bg is removed
If we grab a block group, for example in btrfs_trim_fs(), we will be holding
a reference on it but the block group can be removed after we got it (via
btrfs_remove_block_group), which means it will no longer be part of the
rbtree.
However, btrfs_remove_block_group() was only calling rb_erase() which leaves
the block group's rb_node left and right child pointers with the same content
they had before calling rb_erase. This was dangerous because a call to
next_block_group() would access the node's left and right child pointers (via
rb_next), which can be no longer valid.
Fix this by clearing a block group's node after removing it from the tree,
and have next_block_group() do a tree search to get the next block group
instead of using rb_next() if our block group was removed.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
Diffstat (limited to 'fs/btrfs/super.c')
0 files changed, 0 insertions, 0 deletions