Re: [PATCH RFC v3] btrfs: commit current transaction in btrfs_relocate_block_group
Bartosz Chronowski <[email protected]> Tue, 28 Jul 2026 10:42:08 +0200
| Newsgroups | dev.linux.lists.syzbot |
|---|---|
| Message-ID | <tsuwlgwlnsgq36q7d336qhvt6he44keajnx7wi3xl6otoqsej3@qqj2ta2ov5iz> |
#syz upstream
On Fri, Jul 24, 2026 at 10:24:30PM +0000, syzbot wrote:
> During block group relocation, btrfs_relocate_block_group() is called to
> relocate a block group. It first makes the block group read-only by calling
> btrfs_inc_block_group_ro(). If there are pending space reservations or
> pinned extents in the current transaction, making the block group read-only
> can fail, leading to a transaction abort and a warning in
> cleanup_transaction() during the transaction commit in
> prepare_to_relocate().
>
> To fix this, commit the current transaction before calling
> btrfs_inc_block_group_ro() in btrfs_relocate_block_group(). This drains the
> current transaction before the block group becomes read-only, ensuring that
> pending extents are unpinned and space reservations are committed. This
> does not claim global settlement of every reservation or later transaction,
> but it provides a clean state for marking the block group read-only. The
> setup commit in prepare_to_relocate() remains necessary because it commits
> the transaction started during the relocation setup (such as creating the
> reloc tree) to ensure everything is in a consistent state before starting
> to move extents.
>
> WARNING: fs/btrfs/transaction.c:2068 at cleanup_transaction+0x727/0x7c0
> Call Trace:
> <TASK>
> btrfs_commit_transaction+0x262c/0x30b0 fs/btrfs/transaction.c:2664
> prepare_to_relocate+0x3dd/0x4e0 fs/btrfs/relocation.c:3541
> relocate_block_group+0x141/0xe90 fs/btrfs/relocation.c:3566
> do_nonremap_reloc+0xa7/0x560 fs/btrfs/relocation.c:5323
> btrfs_relocate_block_group+0x6e2/0xaf0 fs/btrfs/relocation.c:5490
> btrfs_relocate_chunk+0x114/0x830 fs/btrfs/volumes.c:3647
> __btrfs_balance+0x1b6e/0x29e0 fs/btrfs/volumes.c:4586
> btrfs_balance+0xaa6/0x1180 fs/btrfs/volumes.c:4973
> btrfs_ioctl_balance+0x3dd/0x640 fs/btrfs/ioctl.c:3474
> </TASK>
>
> Fixes: 3fd0a5585eb9 ("Btrfs: Metadata ENOSPC handling for balance")
> Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot
> Reported-by: [email protected]
> Closes: https://syzkaller.appspot.com/bug?extid=021d10c4d4edc87daa03
> Link: https://syzkaller.appspot.com/ai_job?id=ca6bd6c4-fbcf-4533-af07-79b4a0eba74d
> To: "Chris Mason" <[email protected]>
> To: "David Sterba" <[email protected]>
> To: <[email protected]>
> To: "Yan, Zheng" <[email protected]>
> Cc: <[email protected]>
>
> ---
> v3:
> - Updated the commit description to clarify that the new call drains the current transaction before the block group becomes read-only.
> - Clarified that this does not claim global settlement of every reservation or later transaction.
> - Explained why the setup commit in prepare_to_relocate() remains necessary.
>
> v2:
> - Replaced the transaction abort changes in the commit path with committing the current transaction before making the block group read-only during relocation.
> - Removed changes to fs/btrfs/qgroup.c, fs/btrfs/root-tree.c, fs/btrfs/transaction.c, and fs/btrfs/transaction.h.
> - Added a call to btrfs_commit_current_transaction() in btrfs_relocate_block_group() before calling btrfs_inc_block_group_ro().
> https://lore.kernel.org/all/[email protected]/T/
>
> v1:
> https://lore.kernel.org/all/[email protected]/T/
> ---
> diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
> index fb85bc8b3..05f5110c2 100644
> --- a/fs/btrfs/relocation.c
> +++ b/fs/btrfs/relocation.c
> @@ -5430,6 +5430,10 @@ int btrfs_relocate_block_group(struct btrfs_fs_info *fs_info, u64 group_start,
> if (ret < 0)
> goto out_put_rc;
>
> + ret = btrfs_commit_current_transaction(extent_root);
> + if (ret)
> + goto out;
> +
> ret = btrfs_inc_block_group_ro(rc->block_group, true);
> if (ret)
> goto out;
>
>
> base-commit: 8cdeaa50eae8dad34885515f62559ee83e7e8dda
> --
> This is an AI-generated patch subject to moderation.
> Reply with '#syz upstream' to Sign-off the patch as a human author
> and send it to the upstream kernel mailing lists.
> Reply with '#syz reject' to reject it ('#syz unreject' to undo).
>
> See https://goo.gle/syzbot-ai-patches for information about AI-generated patches.
> You can comment on the patch as usual, syzbot will try to address
> the comments and send a new version of the patch if necessary.
> syzbot engineers can be reached at [email protected].