On 1.06.20 г. 21:12 ч., fdmanana@xxxxxxxxxx wrote:
> From: Filipe Manana <fdmanana@xxxxxxxx>
>
> Initially when the 'removed' flag was added to a block group to avoid
> races between block group removal and fitrim, by commit 04216820fe83d5
> ("Btrfs: fix race between fs trimming and block group remove/allocation"),
> we had to lock the chunks mutex because we could be moving the block
> group from its current list, the pending chunks list, into the pinned
> chunks list, or we could just be adding it to the pinned chunks if it was
> not in the pending chunks list. Both lists were protected by the chunk
> mutex.
>
> However we no longer have those lists since commit 1c11b63eff2a67
> ("btrfs: replace pending/pinned chunks lists with io tree"), and locking
> the chunk mutex is no longer necessary because of that. The same happens
> at btrfs_unfreeze_block_group(), we lock the chunk mutex because the block
> group's extent map could be part of the pinned chunks list and the call
> to remove_extent_mapping() could be deleting it from that list, which
> used to be protected by that mutex.
>
> So just remove those lock and unlock calls as they are not needed anymore.
>
> Signed-off-by: Filipe Manana <fdmanana@xxxxxxxx>
The critical section really involves checking btrfs_block_group::frozen
and btrfs_block_group::removed atomically which is ensured by holding
btrfs_block_group::lock. And in the unfreeze function we only modify the
mapping tree under the tree's write lock, so:
Reviewed-by: Nikolay Borisov <nborisov@xxxxxxxx>
