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

["Stéphane Lesimple" <stephane_btrfs@lesimple.fr>]

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)

(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.

-- 
Stéphane.