From 8dbcd10f6978ca3ccee2f43288d16b7b9da2fb2b Mon Sep 17 00:00:00 2001 From: Filipe Manana Date: Tue, 2 Dec 2014 18:07:49 +0000 Subject: 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 Signed-off-by: Chris Mason --- fs/btrfs/extent-tree.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'fs/btrfs') diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index ba7042e2390b..17b052ae4653 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -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); -- cgit v1.2.3