Re: Tc bug (kernel crash) more info

[Badalian Vyacheslav <slavon@bigtelecom.ru>]

I found that bug in this place

(gdb) l *0xc01c8973
0xc01c8973 is in rb_insert_color (lib/rbtree.c:80).
75
76              while ((parent = rb_parent(node)) && rb_is_red(parent))
77              {
78                      gparent = rb_parent(parent);
79
80                      if (parent == gparent->rb_left)
81                      {
82                              {
83                                      register struct rb_node *uncle = 
gparent->rb_right;
84                                      if (uncle && rb_is_red(uncle))


if i not wrong understand message "unable to handle kernel NULL pointer 
dereference at virtual address 00000008" its was known that "gparent == 
Null"?
Or i hope or i try find a mare's-nest?

> Ok =) I hope in next week you found bug place and fix it!
>
> PS. if you ask where i can read "kernel panic dump logic" literature 
> and try find bugline in code.
> I read dump and see that bug in function "rb_insert_color" + some 
> shift (in asm?) that called from htb_dequeue? But in htb_dequeue not 
> have calling rb_insert_color =( Or some nodes in trace was skipped?
>
> Its for change up my education ;)
>> I'll not be able to assist you until monday (but I'll try to look
>> into the code and maybe to prepare some new patch - but it needs
>> a lot of checking to not add too much of this locking as well).
>>
>> I think you can stay with a kernel whichever you like - I'm not sure
>> any config changes or even more debugging can change much, but maybe
>> I'm wrong. It looks to me like some locking is missing or interrupted.
>> If you are working weekends and find something new, don't wait: maybe
>> somebody else here could be interested too.
>>  
>> Cheers,
>> Jarek P.
>>   
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>