summaryrefslogtreecommitdiff
path: root/fs/btrfs
diff options
context:
space:
mode:
authorJosef Bacik <jbacik@fusionio.com>2013-01-28 14:45:20 (GMT)
committerJosef Bacik <jbacik@fusionio.com>2013-02-05 21:09:03 (GMT)
commit222c81dc3874b4fe98371be665d0447a36447653 (patch)
tree534dba9dae10fa3b8cdc4111176b3ec7450e922b /fs/btrfs
parent1eafa6c73791e4f312324ddad9cbcaf6a1b6052b (diff)
downloadlinux-222c81dc3874b4fe98371be665d0447a36447653.tar.xz
Btrfs: do not merge logged extents if we've removed them from the tree
You can run into this problem where if somebody is fsyncing and writing out the existing extents you will have removed the extent map from the em tree, but it's still valid for the current fsync so we go ahead and write it. The problem is we unconditionally try to merge it back into the em tree, but if we've removed it from the em tree that will cause use after free problems. Fix this to only merge if we are still a part of the tree. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Diffstat (limited to 'fs/btrfs')
-rw-r--r--fs/btrfs/extent_map.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c
index ed88f5e..9759911 100644
--- a/fs/btrfs/extent_map.c
+++ b/fs/btrfs/extent_map.c
@@ -289,7 +289,8 @@ out:
void clear_em_logging(struct extent_map_tree *tree, struct extent_map *em)
{
clear_bit(EXTENT_FLAG_LOGGING, &em->flags);
- try_merge_map(tree, em);
+ if (em->in_tree)
+ try_merge_map(tree, em);
}
/**