[PATCH v2] btrfs: zoned: fix missing chunk metadata reservation
From: Guanghui Yang
Date: Tue Jul 14 2026 - 05:56:07 EST
reserve_chunk_space() stores the return value of
btrfs_zoned_activate_one_bg() in ret. The helper can return 1 after
successfully activating a block group, but ret is later used to decide
whether to reserve metadata for chunk tree updates.
As a result, successful activation skips btrfs_block_rsv_add() and leaves
trans->chunk_bytes_reserved unchanged. Use a separate variable for the
activation result so positive success does not affect the later
reservation. Keep activation failures in ret instead of returning early so
the function uses the common tail path.
Fixes: b6a98021e401 ("btrfs: zoned: activate necessary block group")
Cc: stable@xxxxxxxxxxxxxxx
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@xxxxxxx>
Signed-off-by: Guanghui Yang <3497809730@xxxxxx>
---
Changes since v1:
- Keep activation failures in ret instead of returning early from
reserve_chunk_space(), as suggested by Johannes / sashiko.
Testing:
- Targeted zoned null_blk reproducer with 4G host-managed device,
256MiB zones and zone_max_active=8. The helper returned 1 and
btrfs_block_rsv_add() reserved 393216 bytes in the reproduced path.
- xfstests was not run because the test host does not have an xfstests
tree installed.
fs/btrfs/block-group.c | 34 +++++++++++++++++++---------------
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c
index ab76a5173272..8def7abb728f 100644
--- a/fs/btrfs/block-group.c
+++ b/fs/btrfs/block-group.c
@@ -4532,25 +4532,29 @@ static void reserve_chunk_space(struct btrfs_trans_handle *trans,
if (IS_ERR(bg)) {
ret = PTR_ERR(bg);
} else {
+ int activate_ret;
+
/*
* We have a new chunk. We also need to activate it for
* zoned filesystem.
*/
- ret = btrfs_zoned_activate_one_bg(info, true);
- if (ret < 0)
- return;
-
- /*
- * If we fail to add the chunk item here, we end up
- * trying again at phase 2 of chunk allocation, at
- * btrfs_create_pending_block_groups(). So ignore
- * any error here. An ENOSPC here could happen, due to
- * the cases described at do_chunk_alloc() - the system
- * block group we just created was just turned into RO
- * mode by a scrub for example, or a running discard
- * temporarily removed its free space entries, etc.
- */
- btrfs_chunk_alloc_add_chunk_item(trans, bg);
+ activate_ret = btrfs_zoned_activate_one_bg(info, true);
+ if (activate_ret < 0) {
+ ret = activate_ret;
+ } else {
+ /*
+ * If we fail to add the chunk item here, we end
+ * up trying again at phase 2 of chunk allocation,
+ * at btrfs_create_pending_block_groups(). So
+ * ignore any error here. An ENOSPC here could
+ * happen, due to the cases described at
+ * do_chunk_alloc() - the system block group we
+ * just created was just turned into RO mode by a
+ * scrub for example, or a running discard
+ * temporarily removed its free space entries, etc.
+ */
+ btrfs_chunk_alloc_add_chunk_item(trans, bg);
+ }
}
}
base-commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa
--
2.52.0.windows.1