4.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <fdman...@suse.com>
commit a96295965b600f2dc6ad661c4803c86e87db3d7b upstream.
If while setting a block group read-only we end up allocating a system
chunk, through check_system_chunk(), we were not doing it while holding
the chunk mutex which is a problem if a concurrent chunk allocation is
happening, through do_chunk_alloc(), as it means both block groups can
end up using the same logical addresses and physical regions in the
device(s). So make sure we hold the chunk mutex.
Fixes: 2f0810880f08 ("btrfs: delete chunk allocation attemp when
setting block group ro")
Signed-off-by: Filipe Manana <fdman...@suse.com>
Signed-off-by: Chris Mason <c...@fb.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
fs/btrfs/extent-tree.c | 2 ++
fs/btrfs/volumes.c | 1 +
2 files changed, 3 insertions(+)
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -8548,7 +8548,9 @@ int btrfs_set_block_group_ro(struct btrf
out:
if (cache->flags & BTRFS_BLOCK_GROUP_SYSTEM) {
alloc_flags = update_block_group_flags(root, cache->flags);
+ lock_chunks(root->fs_info->chunk_root);
check_system_chunk(trans, root, alloc_flags);
+ unlock_chunks(root->fs_info->chunk_root);
}
btrfs_end_transaction(trans, root);
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -4626,6 +4626,7 @@ int btrfs_alloc_chunk(struct btrfs_trans
{
u64 chunk_offset;
+ ASSERT(mutex_is_locked(&extent_root->fs_info->chunk_mutex));
chunk_offset = find_next_chunk(extent_root->fs_info);
return __btrfs_alloc_chunk(trans, extent_root, chunk_offset, type);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
