summaryrefslogtreecommitdiffstats
path: root/fs/btrfs/block-group.c
diff options
context:
space:
mode:
authorFilipe Manana <fdmanana@suse.com>2023-11-21 14:38:35 +0100
committerDavid Sterba <dsterba@suse.com>2023-12-15 20:27:01 +0100
commit3128b548c759da4263b44306093d3a1751dcc58d (patch)
tree7ab87a22237ec8d5b807b77e9947f8ed5d0d94f9 /fs/btrfs/block-group.c
parentbtrfs: mark sanity checks when getting chunk map as unlikely (diff)
downloadlinux-3128b548c759da4263b44306093d3a1751dcc58d.tar.xz
linux-3128b548c759da4263b44306093d3a1751dcc58d.zip
btrfs: split assert into two different asserts when removing block group
When starting a transaction to remove a block group we have one ASSERT that checks we found an extent map and that the extent map's start offset matches the desired chunk offset. In case one of the conditions fails, we get a stack trace that point to the respective line of code, however we can't tell which condition failed: either there's no extent map or we got one with an unexpected start offset. To make such an issue easier to debug and analyse, split the assertion into two, one for each condition. This was actually triggered during development of another upcoming change. Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'fs/btrfs/block-group.c')
-rw-r--r--fs/btrfs/block-group.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c
index 6e5dc68ff661..fca653cc977c 100644
--- a/fs/btrfs/block-group.c
+++ b/fs/btrfs/block-group.c
@@ -1303,7 +1303,8 @@ struct btrfs_trans_handle *btrfs_start_trans_remove_block_group(
read_lock(&em_tree->lock);
em = lookup_extent_mapping(em_tree, chunk_offset, 1);
read_unlock(&em_tree->lock);
- ASSERT(em && em->start == chunk_offset);
+ ASSERT(em != NULL);
+ ASSERT(em->start == chunk_offset);
/*
* We need to reserve 3 + N units from the metadata space info in order