Re: [PATCH] btrfs: tree-checker: dump the page status if hit something wrong

From: Tavian Barnes <tavianator@tavianator.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: linux-btrfs@vger.kernel.org, wqu@suse.com
Subject: Re: [PATCH] btrfs: tree-checker: dump the page status if hit something wrong
Date: Tue, 6 Feb 2024 16:48:42 -0500	[thread overview]
Message-ID: <CABg4E-=A+Ga2RtTW4tdJUhTQSNtg3HAvSYmGQaoPKJ-qh-UVJA@mail.gmail.com> (raw)
In-Reply-To: <60724d87-293d-495f-92ed-80032dab5c47@gmx.com>

On Tue, Feb 6, 2024 at 3:40 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
> On 2024/2/7 06:42, Tavian Barnes wrote:
> > On Tue, 6 Feb 2024 16:24:32 +1030, Qu Wenruo wrote:
> >> Maybe it's missing some fixes not yet in upstream?
> >> My current guess is related to my commit 09e6cef19c9f ("btrfs: refactor
> >> alloc_extent_buffer() to allocate-then-attach method"), but since I can
> >> not reproduce it, it's only a guess...
> >
> > That's possible!  I tried to follow the existing code in
> > alloc_extent_buffer() but didn't see any obvious races.  I will try again
> > with the for-next tree and report back.
>
> The most obvious way to proof is, if you can reproduce it really
> reliably, then just go back to that commit and verify (it can still
> cause the problem).
> Then go one commit before for, and verify it doesn't cause the problem
> anymore.

I just tried the tip of btrfs/for-next (6a1dc34172e0, "btrfs: move
transaction abort to the error site btrfs_rebuild_free_space_tree()"),
plus the dump_page() patch, and it still reproduces:

    BTRFS critical (device dm-2): inode mode mismatch with dir: inode
mode=0142721 btrfs type=6 dir type=1
    page:000000004209c922 refcount:4 mapcount:0
mapping:000000007cadbbf5 index:0x8379d17c pfn:0x13ca315
    memcg:ffff8f2cba7d0000
    aops:btree_aops [btrfs] ino:1
    flags: 0x12ffff180000820c(referenced|uptodate|workingset|private|node=2|zone=2|lastcpupid=0xffff)
    page_type: 0xffffffff()
    raw: 12ffff180000820c 0000000000000000 dead000000000122 ffff8f1d446218a0
    raw: 000000008379d17c ffff8f2faa26ea50 00000004ffffffff ffff8f2cba7d0000
    page dumped because: eb page dump
    BTRFS critical (device dm-2): corrupted leaf, root=518
block=9034951802880 owner mismatch, have 15999665770497355816 expect
[256, 18446744073709551360]

Is it still worth trying that specific commit?  I'm guessing not.

> Although without a way to reproduce locally, it's really hard to say or
> debug from my end.

I can try to make a VM image reproducer if that would help.

> Thanks,
> Qu

-- 
Tavian Barnes