Re: [GIT PULL] Btrfs fixes for 6.8-rc2

From: Qu Wenruo
Date: Fri Jan 26 2024 - 16:39:58 EST



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@xxxxxxxx> 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)

Attachment: OpenPGP_0xC23D91F3A125FEA8.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature