Date: Sat, 27 Jan 2024 08:09:39 +1030
From: Qu Wenruo <wqu@...e.com>
To: dsterba@...e.cz, Linus Torvalds <torvalds@...ux-foundation.org>
Cc: David Sterba <dsterba@...e.com>, linux-btrfs@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] Btrfs fixes for 6.8-rc2



On 2024/1/27 06:30, David Sterba wrote:
> On Fri, Jan 26, 2024 at 11:25:19AM -0800, Linus Torvalds wrote:
>> On Mon, 22 Jan 2024 at 10:34, David Sterba <dsterba@...e.com> wrote:
>>>
>>>    git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git tags/for-6.8-rc1-tag
>>
>> I have no idea if this is related to the new fixes, but I have never
>> seen it before:
>>
>>    BTRFS critical (device dm-0): corrupted node, root=256
>> block=8550954455682405139 owner mismatch, have 11858205567642294356
>> expect [256, 18446744073709551360]
> 
> Whick check: the numbers don't match constaints, blocks must be 4096
> aligned
> 
> hex(8550954455682405139) = 0x76ab17c5c57e5313
> (would have to end with 3 zeros)

Oh, I forgot the most obvious problem.

This means the extent buffer is full of garbage.

And this is means the content of the eb got some sudden change.
As during extent buffer read, we have a very basic eb bytenr check 
against the eb read from disk.

So it means at that point, at least we got something correct, and can 
even pass csum checks.

But later one, the pages of the eb got corrupted and we got garbarge.

(AKA, my previous analyse is totally wrong, but it may still inspire me 
to add extra check on eb_owner to reject higher level qgroup subvolumes)


What's the page size of the system? 4K or 16K or 64K?

For the first 2, the eb handling would go the regular path as 4K page 
sized systems (as 16K is the default nodesize, nodesize >= PAGE_SIZE 
would share the same page based eb handling).

For 64K, it would go full subpage, but I doubt it, as the Apple M series 
CPUs do not seem to support 64K page size.

Thanks,
Qu
> 
> and owner is sequentially increased such a high number is unlikely to be
> reached on nowadays systems.
> 
>>    BTRFS critical (device dm-0): corrupted node, root=256
>> block=8550954455682405139 owner mismatch, have 11858205567642294356
>> expect [256, 18446744073709551360]
>>    BTRFS critical (device dm-0): corrupted node, root=256
>> block=8550954455682405139 owner mismatch, have 11858205567642294356
>> expect [256, 18446744073709551360]
>>    SELinux: inode_doinit_use_xattr:  getxattr returned 117 for dev=dm-0
>> ino=5737268
>>    SELinux: inode_doinit_use_xattr:  getxattr returned 117 for dev=dm-0
>> ino=5737267
>>
>> and it caused an actual warning to be printed for my kernel tree from 'git':
>>
>>     error: failed to stat 'sound/pci/ice1712/se.c': Structure needs cleaning
> 
> Size of sound/pci/ice1712/se.c is 19875, this does not look like it
> would be caused by the zstd bug as it was for inlined files where the
> limit is 2048 bytes.
> 
>> (and yes, 117 is EUCLEAN, aka "Structure needs cleaning")
>>
>> The problem seems to have self-corrected, because it didn't happen
>> when repeating the command, and that file that failed to stat looks
>> perfectly fine.
>>
>> But it is clearly worrisome.
>>
>> The "owner mismatch" check isn't new - it was added back in 5.19 in
>> commit 88c602ab4460 ("btrfs: tree-checker: check extent buffer owner
>> against owner rootid"). So something else must have changed to trigger
>> it.
> 
> This looks like garbage data got read from disk, yet still passing the
> checksum test (otherwise that would lead to an EIO and would not get to
> the tree-checker).  Most likely cause is that damaged data were written
> to the disk before.
> 
> The tree-checker also verifies data before they get written, the same
> bogus values of block/owner would trigger it so you'd see a warning.
> 
> It's not possible to get the data damaged on the way from the device to
> the filesystem, that would not pass the checksum, so unlikely a
> driver/block layer bug.
> 
> What remains that the data were correctly written in the past, read
> correctly passing checksum test but then somehow got damaged in the
> memory between the checksum check and tree-checker. The window is quite
> short:
> 
> disk-io.c:btrfs_validate_extent_buffer()
> 
> between csum_tree_block() (around line 397) and
>          btrfs_check_node() (around line 464)

Download attachment "OpenPGP_0xC23D91F3A125FEA8.asc" of type "application/pgp-keys" (6918 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (496 bytes)

Powered by blists - more mailing lists