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. Thanks, Qu
Attachment:
signature.asc
Description: OpenPGP digital signature
