[Top] [All Lists]

Re: ACPI/HT or Packet Scheduler BUG?

To: Thomas Graf <tgraf@xxxxxxx>
Subject: Re: ACPI/HT or Packet Scheduler BUG?
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Sat, 16 Apr 2005 11:49:06 +1000
Cc: Steven Rostedt <rostedt@xxxxxxxxxxx>, hadi@xxxxxxxxxx, netdev <netdev@xxxxxxxxxxx>, Tarhon-Onu Victor <mituc@xxxxxxxxxxxxxx>, kuznet@xxxxxxxxxxxxx, devik@xxxxxx, linux-kernel@xxxxxxxxxxxxxxx, Patrick McHardy <kaber@xxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>
In-reply-to: <20050415225422.GF4114@xxxxxxxxxxxxxx>
References: <Pine.LNX.4.61.0504081225510.27991@xxxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.61.0504121526550.4822@xxxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.61.0504141840420.13546@xxxxxxxxxxxxxxxxxxxxxxxx> <1113601029.4294.80.camel@xxxxxxxxxxxxxxxxxxxxx> <1113601446.17859.36.camel@xxxxxxxxxxxxxxxxxxxxx> <1113602052.4294.89.camel@xxxxxxxxxxxxxxxxxxxxx> <20050415225422.GF4114@xxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
On Fri, Apr 15, 2005 at 10:54:22PM +0000, Thomas Graf wrote:
> Another case were it's not locked is upon a deletion of a class where
> the class deletes its inner qdisc, although there is only one case
> how this can happen and that's under rtnl semaphore so there is no
> way we can have a dumper at the same time.

Sorry, that's where tc went astray :)

The assumption that the rtnl is held during dumping is false.  It is
only true for the initial dump call.  All subsequent dumps are not
protected by the rtnl.

The solution is certainly not to place the dumpers under rtnl :)
The dump operation is read-only and should not need any exclusive

In fact the whole qdisc locking is a mess.  It's a cross-breed
between locking with ad-hoc reference counting and RCU.  What's
more, the RCU is completely useless too because for the case
where we actually have a queue we still end up taking the spin
lock on each transmit! I think someone's been benchmarking the
loopback device again :)

It needs to be reengineered.

Here is a quick'n'dirty fix to the problem at hand.  What happened
between 2.6.10-rc1 and 2.6.10-rc2 is that qdisc_destroy started
changing the next pointer of qdisc entries which totally confuses
the readers because qdisc_destroy doesn't always take the tree lock.

This patch tries to ensure that all top-level calls to qdisc_destroy
come under the tree lock.  As Thomas correctedly pointed out, most
of the other qdisc_destroy calls occur after the top qdisc has been
unlinked from the device qdisc_list.  However, someone should go
through each one of the remaining ones (they're all in the individual
sch_* implementations) and make sure that this assumption is really

Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>

If anyone has cycles to spare and a stomach strong enough for
this stuff, here is your chance :)

Visit Openswan at
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page:
PGP Key:

Attachment: p
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>