Re: [BUG] btrfs: WARNING in invalidate_and_check_btree_folios, during unmount on 7.4-rc1

[Qu Wenruo]

在 2026/11/5 16:12, 铮 写道:
> Hi Btrfs maintainers,
[...]
> We also reproduced the warning with panic_on_warn=0, allowing the
> kernel to print the extent buffer diagnostics following the WARN.
>
> Four instances were captured:
>
>      BTRFS warning (device loop4 state I): unable to release extent
> buffer 6881280 owner 5 gen 9 refs 2 flags 0xd

0xd means UPTODATE | TREE_REF | STALE.

Meaning the eb is already being released, so this means there are some 
races.

>      BTRFS warning (device loop0 state I): unable to release extent
> buffer 6885376 owner 5 gen 9 refs 2 flags 0x1d

This is UPTODATE | TREE_REF | STALE | WRITEBACK, which is also stale but 
also under writeback.

Exactly what the check is supposed to catch.

>      BTRFS warning (device loop8 state I): unable to release extent
> buffer 6885376 owner 5 gen 9 refs 2 flags 0x1d
>      BTRFS warning (device loop1 state I): unable to release extent
> buffer 6885376 owner 5 gen 9 refs 2 flags 0x5

This is UPTODATE | TREE_REF.

Combined with the 0xd one, I guess someone else is holding the eb, not 
yet reached the releasing part.

I guess you have already passed all the info into an LLM, and no obvious 
cause can be pinned down.

So far I'd say finding a minimal reproducer would be the best way to 
continue.

No human will be happy waiting over 1000s just for one single triggering.

> In all four instances, the recorded reference count was 2,
> corresponding to the expected baseline references described in
> invalidate_and_check_btree_folios().
>
> Two instances had EXTENT_BUFFER_WRITEBACK set (flags 0x1d), indicating
> that the extent buffer was marked as under writeback when its flags
> were printed.
>
> The other two instances (flags 0xd and 0x5) did not have
> EXTENT_BUFFER_DIRTY or EXTENT_BUFFER_WRITEBACK set at print time.
>
> Since WARN_ON_ONCE() is executed before the diagnostic message and the
> flags are read later, these observations may reflect changes in the
> extent buffer state between the initial condition check and the
> diagnostic print.

This is definitely something we can improve.
We should ensure the message is before WARNING/ASSERT/BUG_ON to make 
sure syzbot can catch the problem.

I can easily craft a patch re-ordering those call sites.

Thanks,
Qu