Re: [PATCH v5 09/16] btrfs: handle deletions from remapped block group

[Mark Harmstone <mark@harmstone.com>]

On 12/11/2025 6.51 pm, Mark Harmstone wrote:
... snip ...
>> As far as I can tell, this code is called from contexts which might not
>> be holding the reclaim mutex (extent freeing delayed ref logic) which
>> means it could run concurrently with btrfs_delete_unused_bgs(). Or is
>> the fact that we are not yet fully remapped mean that the remap logic is
>> still running while holding that mutex, so delete_unused_bgs can't run?
>>
>> With that in mind, I am somewhat concerned about the possibility that we
>> might be *on* the unused bgs list at this time, unless you know the
>> delete can't run concurrently, or that the remapped handling all assumes
>> it's possible we have concurrently run delete?
> 
> btrfs_mark_bg_fully_remapped() is called when the last identity remap of 
> a BG is removed: either from the relocation thread, or from deleting an 
> inode. So if balance is interrupted, it's possible for it to be run 
> without the reclaim mutex being held.
> 
> I think I need to investigate exactly why this can be called for a BG 
> that's on the unused_bgs list, it's not obvious why that can happen.

The answer is that btrfs_create_pending_block_groups(), which can create 
a new block group to satisfy a reservation, then immediately puts it on 
the unused list.

It remains on that list when allocations are made to it, but 
btrfs_delete_unused_bgs() will remove it from the list but bail when it 
sees it's actually used. (If you're looking to tighten up the BG list 
system this might be of interest.)

So I need to change it so that the bool bg->fully_remapped gets set 
holding the same bg->lock at the same time as identity_remap_count falls 
to 0, rather than later in btrfs_mark_bg_fully_remapped().

This is the fixed version of the potential race:

CPU0					CPU1
----					----

btrfs_create_pending_block_groups()
creates BG and adds to unused list

extent created in BG

balance started

balance cancelled before identity
remap processed (so reclaim mutex
doesn't prevent BG deletion job)

last identity map removed by rm,
bg->fully_remapped set

					btrfs_delete_unused_bgs()
					called, bails because of
					bg->fully_remapped

BG added to fully remapped list