Subject: Re: net_sched 00/07: classful multiqueue dummy scheduler

From: Eric Dumazet <[email-masked]>
Date: Mon, 07 Sep 2009 19:30:47 +0200

Patrick McHardy a écrit :
> Eric Dumazet wrote:
>>> I figured out the bug, which is likely responsible for both
>>> problems. When grafting a mq class and creating a rate estimator,
>>> the new qdisc is not attached to the device queue yet and also
>>> doesn't have TC_H_ROOT as parent, so qdisc_create() selects
>>> qdisc_root_sleeping_lock() for the estimator, which belongs to
>>> the qdisc that is getting replaced.
>>>
>>> This is a patch I used for testing, but I'll come up with
>>> something more elegant (I hope) as a final fix :)
>> Yes, this was the problem, and your patch fixed it.
> 
> Thanks for testing.
> 
>> Now adding CONFIG_SLUB_DEBUG_ON=y for next tries :)
>>
>> Sep  7 16:37:55 erd kernel: [  217.056813] =============================================================================
>> Sep  7 16:37:55 erd kernel: [  217.056865] BUG kmalloc-256: Poison overwritten
>> Sep  7 16:37:55 erd kernel: [  217.056910] -----------------------------------------------------------------------------
>> Sep  7 16:37:55 erd kernel: [  217.056911]
>> Sep  7 16:37:55 erd kernel: [  217.056990] INFO: 0xf6e622bc-0xf6e622bd. First byte 0x76 instead of 0x6b
>> Sep  7 16:37:55 erd kernel: [  217.057049] INFO: Allocated in qdisc_alloc+0x1b/0x80 age=154593 cpu=2 pid=5165
>> Sep  7 16:37:55 erd kernel: [  217.057094] INFO: Freed in qdisc_destroy+0x88/0xa0 age=139186 cpu=4 pid=5173
>> Sep  7 16:37:55 erd kernel: [  217.057139] INFO: Slab 0xc16ddc40 objects=26 used=6 fp=0xf6e62260 flags=0x28040c3
>> Sep  7 16:37:55 erd kernel: [  217.057184] INFO: Object 0xf6e62260 @offset=608 fp=0xf6e62850
>> Sep  7 16:37:55 erd kernel: [  217.057184]
> 
> I'm unable to reproduce this. Could you send me the commands you
> used that lead to this?
> 

Sorry, this was *before* your last patch.

I tried to have more information, because I was not able to get console messages at crash time on this remote dev machine.

enabling SLUB checks got some hint of what the problem was (using memory block after its freeing by qdisc_destroy)