Re: kernel BUG at linux-4.2.0/fs/btrfs/extent-tree.c:1833 on rebalance

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

Stéphane Lesimple wrote on 2015/09/22 16:31 +0200:
> Le 2015-09-22 10:51, Qu Wenruo a écrit :
>>>>>> [92098.842261] Call Trace:
>>>>>> [92098.842277]  [<ffffffffc035a5d8>] ? read_extent_buffer+0xb8/0x110
>>>>>> [btrfs]
>>>>>> [92098.842304]  [<ffffffffc0396d00>] ? btrfs_find_all_roots+0x60/0x70
>>>>>> [btrfs]
>>>>>> [92098.842329]  [<ffffffffc039af3d>]
>>>>>> btrfs_qgroup_rescan_worker+0x28d/0x5a0 [btrfs]
>>>>>
>>>>> Would you please show the code of it?
>>>>> This one seems to be another stupid bug I made when rewriting the
>>>>> framework.
>>>>> Maybe I forgot to reinit some variants or I'm screwing memory...
>>>>
>>>> (gdb) list *(btrfs_qgroup_rescan_worker+0x28d)
>>>> 0x97f6d is in btrfs_qgroup_rescan_worker (fs/btrfs/ctree.h:2760).
>>>> 2755
>>>> 2756    static inline void btrfs_disk_key_to_cpu(struct btrfs_key *cpu,
>>>> 2757                                             struct btrfs_disk_key
>>>> *disk)
>>>> 2758    {
>>>> 2759            cpu->offset =e64_to_cpu(disk->offset);
>>>> 2760            cpu->type =isk->type;
>>>> 2761            cpu->objectid =e64_to_cpu(disk->objectid);
>>>> 2762    }
>>>> 2763
>>>> 2764    static inline void btrfs_cpu_key_to_disk(struct btrfs_disk_key
>>>> *disk,
>>>> (gdb)
>>>>
>>>>
>>>> Does it makes sense ?
>>> So it seems that the memory of cpu key is being screwed up...
>>>
>>> The code is be specific thin inline function, so what about other stack?
>>> Like btrfs_qgroup_rescan_helper+0x12?
>>>
>>> Thanks,
>>> Qu
>> Oh, I forgot that you can just change the number of
>> btrfs_qgroup_rescan_worker+0x28d to smaller value.
>> Try +0x280 for example, which will revert to 14 bytes asm code back,
>> which may jump out of the inline function range, and may give you a
>> good hint.
>>
>> Or gdb may have a better mode for inline function, but I don't know...
>
> Actually, "list -" is our friend here (show 10 lignes before the last
> src output)
No, that's not the case.

List - will only show lines around the source code.

What I need is to get the higher caller stack.
If debugging a running program, it's quite easy to just use frame command.

But in this situation, we don't have call stack, so I'd like to change 
the +0x28d to several bytes backward, until we jump out of the inline 
function call, and see the meaningful codes.


BTW, did you tried the following patch?
https://patchwork.kernel.org/patch/7114321/
btrfs: qgroup: exit the rescan worker during umount

The problem seems a little related to the bug you encountered, so I'd 
recommend to give it a try.

Thanks,
Qu
>
> (gdb) list *(btrfs_qgroup_rescan_worker+0x28d)
> 0x97f6d is in btrfs_qgroup_rescan_worker (fs/btrfs/ctree.h:2760).
> 2755
> 2756    static inline void btrfs_disk_key_to_cpu(struct btrfs_key *cpu,
> 2757                                             struct btrfs_disk_key
> *disk)
> 2758    {
> 2759            cpu->offset = le64_to_cpu(disk->offset);
> 2760            cpu->type = disk->type;
> 2761            cpu->objectid = le64_to_cpu(disk->objectid);
> 2762    }
> 2763
> 2764    static inline void btrfs_cpu_key_to_disk(struct btrfs_disk_key
> *disk,
> (gdb) list -
> 2745                                                struct
> btrfs_disk_key *key)
> 2746    {
> 2747            write_eb_member(eb, h, struct btrfs_free_space_header,
> location, key);
> 2748    }
> 2749
> 2750    /* struct btrfs_disk_key */
> 2751    BTRFS_SETGET_STACK_FUNCS(disk_key_objectid, struct btrfs_disk_key,
> 2752                             objectid, 64);
> 2753    BTRFS_SETGET_STACK_FUNCS(disk_key_offset, struct btrfs_disk_key,
> offset, 64);
> 2754    BTRFS_SETGET_STACK_FUNCS(disk_key_type, struct btrfs_disk_key,
> type, 8);
> (gdb) list -
> 2735
> 2736    static inline void btrfs_free_space_key(struct extent_buffer *eb,
> 2737                                            struct
> btrfs_free_space_header *h,
> 2738                                            struct btrfs_disk_key *key)
> 2739    {
> 2740            read_eb_member(eb, h, struct btrfs_free_space_header,
> location, key);
> 2741    }
> 2742
> 2743    static inline void btrfs_set_free_space_key(struct extent_buffer
> *eb,
> 2744                                                struct
> btrfs_free_space_header *h,
> (gdb)
>
> Lots of inline funcs and macros it seems.
>