On 13/05/2020 14:11, Qu Wenruo wrote:

On 2020/5/13 下午8:06, Johannes Thumshirn wrote:

quoted

On 13/05/2020 13:57, Qu Wenruo wrote:

quoted

On 2020/5/13 下午7:54, Johannes Thumshirn wrote:

quoted

On 13/05/2020 01:04, David Sterba wrote:
[...]

quoted

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.