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

[David Sterba]

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)

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)