On 13/05/2020 14:11, Qu Wenruo wrote: > > > On 2020/5/13 下午8:06, Johannes Thumshirn wrote: >> On 13/05/2020 13:57, Qu Wenruo wrote: >>> >>> >>> On 2020/5/13 下午7:54, Johannes Thumshirn wrote: >>>> On 13/05/2020 01:04, David Sterba wrote: >>>> [...] >>>>> >>>>> Johannes, do you have logs from the test? >>>> >>>> >>>> >>>> I recreated the logs for btrfs/028 (dmesg, kmemleak and fstests log). Please find them attached. >>>> >>> >>> BTW, what's the line of open_ctree+0x137c/0x277a? >> >> >> Here we go: >> (gdb) l *(open_ctree+0x137c/0x277a) >> 0x122acd is in open_ctree (fs/btrfs/disk-io.c:2826). >> 2821 u64 generation; >> 2822 u64 features; >> 2823 u16 csum_type; >> 2824 struct btrfs_key location; >> 2825 struct btrfs_super_block *disk_super; >> 2826 struct btrfs_fs_info *fs_info = btrfs_sb(sb); >> 2827 struct btrfs_root *tree_root; >> 2828 struct btrfs_root *chunk_root; >> 2829 int ret; >> 2830 int err = -EINVAL; >> >> So its: >> 2826 struct btrfs_fs_info *fs_info = btrfs_sb(sb); >> > This doesn't make sense. > > That line doesn't even call read_tree_block() nor even any function call. > > This looks really strange. Indeed, it does. I have no clue what's going on here.
