[BUG] btrfs: transaction abort (-ENOENT) in delayed refs free path

[Tianyu Li]

Hi Btrfs maintainers,

We found a Btrfs bug where a transaction is aborted with error -ENOENT in the delayed refs free path, around do_free_extent_accounting (extent-tree.c). We reproduced this on both 7.0-rc1 and 7.0-rc2 under syzkaller-style workloads.

Observed symptoms (both runs):

- BTRFS: Transaction aborted (error -2)
- WARNING in do_free_extent_accounting / __btrfs_free_extent

Representative stack trace (7.0-rc1):
run_delayed_data_ref
-> run_one_delayed_ref
-> btrfs_run_delayed_refs_for_head
-> __btrfs_run_delayed_refs
-> btrfs_run_delayed_refs
-> btrfs_commit_transaction
-> btrfs_sync_fs
-> sync_filesystem
-> generic_shutdown_super
-> btrfs_kill_super

Representative stack trace (7.0-rc2):
run_delayed_data_ref
-> run_one_delayed_ref
-> btrfs_run_delayed_refs_for_head
-> __btrfs_run_delayed_refs
-> btrfs_run_delayed_refs
-> btrfs_commit_transaction
-> insert_balance_item
-> btrfs_balance
-> btrfs_ioctl_balance
-> btrfs_ioctl
-> __x64_sys_ioctl

From analysis, the failure seems to occur when delayed refs reaches block-group accounting and btrfs_update_block_group cannot find the target block group (returns -ENOENT), which then aborts the transaction. The second trace suggests this is more likely during relocation/balance timing windows, where remap/relocation state and block-group visibility may be temporarily inconsistent.

A possible fix direction is to refine handling of -ENOENT in this specific accounting path, under strict conditions, so known relocation/remap end states are not treated as unconditional fatal errors. A longer-term direction may be to align remap-tree and block-group update semantics so one path does not treat a state as no-op while another treats it as fatal.

We do not have a formal patch yet, but we are happy to provide reproducer details, full logs, and help validate candidate fixes. If useful, we can also test proposed patch sets on our side.

Best regards,
Tianyu Li