Message ID | 8752e4df194f7c765d04a5830716e3218fb22222.1703177167.git.naohiro.aota@wdc.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | btrfs: fix unbalanced unlock of mapping_tree_lock | expand |
On Fri, Dec 22, 2023 at 01:46:16AM +0900, Naohiro Aota wrote: > The error path of btrfs_get_chunk_map() releases > fs_info->mapping_tree_lock. But, it is taken and released in > btrfs_find_chunk_map(). So, there is no need to do so. > > Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com> Thanks, it's from a recent one, 7dc66abb5a47 ("btrfs: use a dedicated data structure for chunk maps"),
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 4c32497311d2..d67785be2c77 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -3087,7 +3087,6 @@ struct btrfs_chunk_map *btrfs_get_chunk_map(struct btrfs_fs_info *fs_info, map = btrfs_find_chunk_map(fs_info, logical, length); if (unlikely(!map)) { - read_unlock(&fs_info->mapping_tree_lock); btrfs_crit(fs_info, "unable to find chunk map for logical %llu length %llu", logical, length); @@ -3095,7 +3094,6 @@ struct btrfs_chunk_map *btrfs_get_chunk_map(struct btrfs_fs_info *fs_info, } if (unlikely(map->start > logical || map->start + map->chunk_len <= logical)) { - read_unlock(&fs_info->mapping_tree_lock); btrfs_crit(fs_info, "found a bad chunk map, wanted %llu-%llu, found %llu-%llu", logical, logical + length, map->start,
The error path of btrfs_get_chunk_map() releases fs_info->mapping_tree_lock. But, it is taken and released in btrfs_find_chunk_map(). So, there is no need to do so. Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com> --- fs/btrfs/volumes.c | 2 -- 1 file changed, 2 deletions(-)