[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <467F8ADA.7060702@trash.net>
Date: Mon, 25 Jun 2007 11:28:58 +0200
From: Patrick McHardy <kaber@...sh.net>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: netdev@...r.kernel.org,
"bugme-daemon@...nel-bugs.osdl.org"
<bugme-daemon@...nel-bugs.osdl.org>, ranko@...dernet.net
Subject: Re: [Bugme-new] [Bug 8668] New: HTB Deadlock
Andrew Morton wrote:
> On Sun, 24 Jun 2007 21:57:19 -0700 (PDT) bugme-daemon@...zilla.kernel.org wrote:
>
>>I've been experiencing problems with HTB where the whole machine locks
>>up. This usually happens when the whole qdisc is being removed and
>>occasionally when a leaf is being removed.
It shouldn't happen when leaves are removed, you might be running
into some endless dequeue loops however that got fixed in 2.6.20.
>>Common is that it always happens when some sort of removal is in
>>progress.
>>
>>Console output I have captured is at the end of this message. The same
>>behavior exists from vanilla 2.6.19.7 and above. It is possible that the
>>problem also exist in the earlier versions however I did not go further
>>back.
>>
>>I also believe I have found where the actual problem is:
>>
>>qdisc_destroy() function is always called with dev->queue_lock locked.
>>htb_destroy() function up the stack is using del_timer_sync() call to
>>deactivate HTB qdisc timers.
>
>
> yep, I would agree with that analysis. del_timer_sync() under a lock is
> quite dangerous in this regard.
>
> If the (misspelled) comment over htb_destroy() is true, current mainline
> appears still to have this bug.
It is. This patch I had originally planned for 2.6.23 switches HTB
to the generic estimator, which shouldn't suffer from this.
Ranko, can you try if it fixes your timer problem?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists