Re: [syzbot] [btrfs?] kernel BUG in prepare_to_merge

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 2023/8/1 19:39, Christoph Hellwig wrote:
With misc-next and your debug patch I first ran into another assert:

[  250.848976][T35903] assertion failed: 0, in fs/btrfs/relocation.c:2042
[  250.849963][T35903] ------------[ cut here ]------------
[  250.850472][T35903] kernel BUG at fs/btrfs/relocation.c:2042!

and here is the output from your assert:

[ 1378.272143][T189001] BTRFS error (device loop1): reloc tree mismatch, root 8 has no reloc root, expect reloc root key (-8, 132, 8) gen 17

Thanks a lot!

This indeed shows what I feared, on-disk corruption.

The root 8 is quota tree, which doesn't need to go through tree-reloc at
all.

The whole tree-relocation idea is for subvolume trees, which would do a
special snapshot for them, and then swap the highest tree nodes between
the tree reloc tree (the special snapshot) and the subvolume tree.

Thus for non-subvolume trees, relocation is done by just COWing the
involved tree blocks and call it a day.

This means we should never hit a reloc tree for non-subvolume trees, and
this looks like a on-disk format corruption.

Maybe I can reject those obviously incorrect reloc trees in tree-checker.

Thanks,
Qu

[ 1378.274019][T189001] ------------[ cut here ]------------
[ 1378.274540][T189001] BTRFS: Transaction aborted (error -117)
[ 1378.277110][T189001] WARNING: CPU: 3 PID: 189001 at fs/btrfs/relocation.c:1946 prepare_to_merge+0x10e0/0x1460





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux