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

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

[铮]

Hi Btrfs maintainers,

We observed a WARNING in invalidate_and_check_btree_folios() during
Btrfs filesystem unmount while running syzkaller on Linux 7.4-rc1.
Because panic_on_warn was enabled, the warning escalated to a kernel
panic.

Kernel information:

- Kernel: 7.4.0-rc1-kernsight-kasan+ #3
- Base: v7.4-rc1 (6628e7d4c), plus one local io_uring SQPOLL fix
(00043c58565e2d0d804f50c2e127f6966cd594af). The Btrfs source is
unmodified.
- Architecture: x86_64
- Environment: QEMU Standard PC (i440FX + PIIX), KVM
- Configuration: KASAN, CONFIG_BTRFS_DEBUG=y (full .config in repository)
- Fuzzing framework: syzkaller

Warning:

    BTRFS info (device loop3): last unmount of filesystem
    0cb7aac4-39d5-48d7-a0de-5529c14770b2

    ------------[ cut here ]------------
    IS_ENABLED(CONFIG_BTRFS_DEBUG)
    WARNING: fs/btrfs/disk-io.c:3326 at
    invalidate_and_check_btree_folios+0x5ce/0xbe0

    Call Trace:
      close_ctree+0xac9/0x16a0
      generic_shutdown_super+0x169/0x3a0
      kill_anon_super+0x3f/0x70
      btrfs_kill_super+0x41/0x60
      deactivate_locked_super
      deactivate_super
      cleanup_mnt
      task_work_run
    ...

    Kernel panic - not syncing: kernel: panic_on_warn set ...

Some initial reports carried the SOFTLOCKUP taint flag (L). We have
not established whether an earlier soft lockup contributed to those
reports. At least one independent reproduction was reported as "Not
tainted" at the warning site.

Reproduction:

- The warning was observed 19 times during concurrent syzkaller
fuzzing, with the same warning site and call chain.
- We reproduced it three times on fresh QEMU VMs by replaying a
recorded set of 483 syzkaller programs extracted from the crash-store
execution logs and a state-primed recipe.
- The reproductions used syz-execprog -procs=8 -threaded -repeat=0.
- Time to warning was approximately 32 minutes, 45 minutes and 2
hours, respectively (kernel uptime 1807 s, 2732 s and 7445 s).
- We have not yet obtained a minimized single-program reproducer.
Automated minimization did not converge.

Additional diagnostics:

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
    BTRFS warning (device loop0 state I): unable to release extent
buffer 6885376 owner 5 gen 9 refs 2 flags 0x1d
    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

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.

The results suggest that the warning may involve extent buffer I/O
state during filesystem teardown rather than an additional reference
holder. However, we have not established the underlying cause.

Related fixes:

We checked two previous fixes associated with extent buffer cleanup
and reference-counting warnings:

- 4066c55e109475a06d18a1f127c939d551211956
- 690c2accacb1aca91ab8186d15dee56da8723f31

The corresponding dirty-pages cleanup and reference-count
synchronization logic is present in the tested source tree.

We are not yet sure whether this is another manifestation of a known
issue or a separate extent buffer lifetime problem.

Logs and reproduction evidence:

Repository:
https://github.com/Zheng-zheng-codes/btrfs-extent-buffer-warning-repro

Kernel configuration:
https://github.com/Zheng-zheng-codes/btrfs-extent-buffer-warning-repro/blob/main/config/kernel-7.4-rc1-kasan.config

Initial warning and call trace:
https://github.com/Zheng-zheng-codes/btrfs-extent-buffer-warning-repro/blob/main/logs/kernel-warning.log

Full serial console (independent reproduction):
https://github.com/Zheng-zheng-codes/btrfs-extent-buffer-warning-repro/blob/main/logs/external-repro-full-serial.log

Additional reproductions:
https://github.com/Zheng-zheng-codes/btrfs-extent-buffer-warning-repro/blob/main/logs/serial-btrfs-repro2.log
https://github.com/Zheng-zheng-codes/btrfs-extent-buffer-warning-repro/blob/main/logs/serial-btrfs-repro3.log

Extent buffer refs/flags diagnostics:
https://github.com/Zheng-zheng-codes/btrfs-extent-buffer-warning-repro/blob/main/logs/refcap-refs-flags-diagnostic.log

Syzkaller execution log:
https://github.com/Zheng-zheng-codes/btrfs-extent-buffer-warning-repro/blob/main/logs/syzkaller-execution-log0.txt

Reproduction program set:
https://github.com/Zheng-zheng-codes/btrfs-extent-buffer-warning-repro/blob/main/repro/program-set.db

Reproduction results:
https://github.com/Zheng-zheng-codes/btrfs-extent-buffer-warning-repro/blob/main/REPRO-RESULTS.md

Could you please advise whether this warning is related to a known
issue or whether further diagnostics would be useful?

Thanks,
Zheng Zheng

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