OpenE2K
/
linux
6
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Btrfs: fix unprotected deletion from pending_chunks list 

On block group remove if the corresponding extent map was on the
transaction->pending_chunks list, we were deleting the extent map
from that list, through remove_extent_mapping(), without any
synchronization with chunk allocation (which iterates that list
and adds new elements to it). Fix this by ensure that this is done
while the chunk mutex is held, since that's the mutex that protects
the list in the chunk allocation code path.

This applies on top (depends on) of my previous patch titled:
"Btrfs: fix race between fs trimming and block group remove/allocation"

But the issue in fact was already present before that change, it only
became easier to hit after Josef's 3.18 patch that added automatic
removal of empty block groups.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
This commit is contained in:
Filipe Manana 2014-12-02 18:07:49 +00:00 committed by Chris Mason
parent 495e64f4fe
commit 8dbcd10f69
1 changed files with 7 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
fs/btrfs/extent-tree.c
View File

@ -9514,19 +9514,25 @@ int btrfs_remove_block_group(struct btrfs_trans_handle *trans,
list_move_tail(&em->list, &root->fs_info->pinned_chunks);
}
spin_unlock(&block_group->lock);
unlock_chunks(root);
if (remove_em) {
struct extent_map_tree *em_tree;
em_tree = &root->fs_info->mapping_tree.map_tree;
write_lock(&em_tree->lock);
/*
* The em might be in the pending_chunks list, so make sure the
* chunk mutex is locked, since remove_extent_mapping() will
* delete us from that list.
*/
remove_extent_mapping(em_tree, em);
write_unlock(&em_tree->lock);
/* once for the tree */
free_extent_map(em);
}
unlock_chunks(root);
btrfs_put_block_group(block_group);
btrfs_put_block_group(block_group);