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