mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Thomas Graf <tgraf@suug.ch>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	hadi@cyberus.ca, netdev <netdev@oss.sgi.com>,
	Tarhon-Onu Victor <mituc@iasi.rdsnet.ro>,
	kuznet@ms2.inr.ac.ru, devik@cdi.cz, linux-kernel@vger.kernel.org,
	Patrick McHardy <kaber@trash.net>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: ACPI/HT or Packet Scheduler BUG?
Date: Sat, 16 Apr 2005 11:49:06 +1000	[thread overview]
Message-ID: <20050416014906.GA3291@gondor.apana.org.au> (raw)
In-Reply-To: <20050415225422.GF4114@postel.suug.ch>

[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]

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

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

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

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

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[-- Attachment #2: p --]
[-- Type: text/plain, Size: 966 bytes --]

===== net/sched/sch_api.c 1.47 vs edited =====
--- 1.47/net/sched/sch_api.c	2005-04-01 14:35:56 +10:00
+++ edited/net/sched/sch_api.c	2005-04-16 08:47:16 +10:00
@@ -608,9 +608,9 @@
 			return err;
 		if (q) {
 			qdisc_notify(skb, n, clid, q, NULL);
-			spin_lock_bh(&dev->queue_lock);
+			qdisc_lock_tree(dev);
 			qdisc_destroy(q);
-			spin_unlock_bh(&dev->queue_lock);
+			qdisc_unlock_tree(dev);
 		}
 	} else {
 		qdisc_notify(skb, n, clid, NULL, q);
@@ -743,17 +743,17 @@
 		err = qdisc_graft(dev, p, clid, q, &old_q);
 		if (err) {
 			if (q) {
-				spin_lock_bh(&dev->queue_lock);
+				qdisc_lock_tree(dev);
 				qdisc_destroy(q);
-				spin_unlock_bh(&dev->queue_lock);
+				qdisc_unlock_tree(dev);
 			}
 			return err;
 		}
 		qdisc_notify(skb, n, clid, old_q, q);
 		if (old_q) {
-			spin_lock_bh(&dev->queue_lock);
+			qdisc_lock_tree(dev);
 			qdisc_destroy(old_q);
-			spin_unlock_bh(&dev->queue_lock);
+			qdisc_unlock_tree(dev);
 		}
 	}
 	return 0;

  reply	other threads:[~2005-04-16  1:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-08 10:13 Tarhon-Onu Victor
2005-04-12 12:46 ` Tarhon-Onu Victor
2005-04-14 15:46   ` Tarhon-Onu Victor
2005-04-15 21:37     ` Steven Rostedt
2005-04-15 21:44       ` jamal
2005-04-15 21:54         ` Steven Rostedt
2005-04-15 22:54           ` Thomas Graf
2005-04-16  1:49             ` Herbert Xu [this message]
2005-04-16  5:01               ` Steven Rostedt
2005-04-16 11:06               ` Thomas Graf
2005-04-16 11:12                 ` Herbert Xu
2005-04-17 17:46                   ` Patrick McHardy
2005-04-17 21:37                     ` Herbert Xu
2005-04-16 11:23                 ` Herbert Xu
2005-04-16 11:34                   ` Thomas Graf
2005-04-16 16:04                     ` jamal
2005-04-16 18:21                       ` Thomas Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050416014906.GA3291@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=davem@davemloft.net \
    --cc=devik@cdi.cz \
    --cc=hadi@cyberus.ca \
    --cc=kaber@trash.net \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mituc@iasi.rdsnet.ro \
    --cc=netdev@oss.sgi.com \
    --cc=rostedt@goodmis.org \
    --cc=tgraf@suug.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®