Re: [PATCH] btrfs: avoid GFP_ATOMIC allocations in qgroup free paths

[David Sterba <dsterba@suse.cz>]

On Thu, Mar 19, 2026 at 04:49:08PM -0700, Leo Martins wrote:
> When qgroups are enabled, __btrfs_qgroup_release_data() and
> qgroup_free_reserved_data() pass an extent_changeset to
> btrfs_clear_record_extent_bits() to track how many bytes had their
> EXTENT_QGROUP_RESERVED bits cleared. Inside the extent IO tree spinlock,
> add_extent_changeset() calls ulist_add() with GFP_ATOMIC to record each
> changed range. If this allocation fails, it hits a BUG_ON and panics the
> kernel.
> 
> However, both of these callers only read changeset.bytes_changed
> afterwards — the range_changed ulist is populated and immediately freed
> without ever being iterated. The GFP_ATOMIC allocation is entirely
> unnecessary for these paths.
> 
> Introduce extent_changeset_init_bytes_only() which uses a sentinel value
> (EXTENT_CHANGESET_BYTES_ONLY) on the ulist's prealloc field to signal
> that only bytes_changed should be tracked. add_extent_changeset() checks
> for this sentinel and returns early after updating bytes_changed,
> skipping the ulist_add() call entirely. This eliminates the GFP_ATOMIC
> allocation and makes the BUG_ON unreachable for these paths.
> 
> Callers that need range tracking (qgroup_reserve_data,
> qgroup_unreserve_range, btrfs_qgroup_check_reserved_leak) continue to
> use extent_changeset_init() and are unaffected.
> 
> Signed-off-by: Leo Martins <loemra.dev@gmail.com>

Added to for-next, thanks.