On Wed, Aug 13, 2008 at 03:19:18PM -0700, David Miller wrote:

...

quoted text
> Ok, so what I'm going to do is check in my patch and then try

> to figure out how to resolve this "both bits clear" scenerio.

BTW, here is my older doubt revisited, where I hope to be re-considered/

re-convinced, if possible...
Thanks,

Jarek P.
---------------->
pkt_sched: Destroy qdiscs under rtnl_lock again.
We don't need to trigger __qdisc_destroy() as an RCU callback because

the use of qdisc isn't controlled by RCU alone: after querying RCU

with synchronize_rcu() in dev_deactivate() we additionaly wait in a

loop checking some flags. After the loop is done there could be no

outstanding use of the qdisc, so call_rcu() doesn't make any sense.
On the other hand, current calling Qdisc's ->destroy() from a softirq

context without locking (rtnl) can break various things like:

qdisc_put_rtab(), tcf_destroy_chain() (e.g. u32_destroy()), and

probably more.
Signed-off-by: Jarek Poplawski 
---
 net/sched/sch_generic.c |    8 ++------

 1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c

index 4685746..e7379d2 100644

--- a/net/sched/sch_generic.c

+++ b/net/sched/sch_generic.c

@@ -518,12 +518,8 @@ void qdisc_reset(struct Qdisc *qdisc)

 }

 EXPORT_SYMBOL(qdisc_reset);
-/* this is the rcu callback function to clean up a qdisc when there

- * are no further references to it */

-

-static void __qdisc_destroy(struct rcu_head *head)

+static void __qdisc_destroy(struct Qdisc *qdisc)

 {

-	struct Qdisc *qdisc = container_of(head, struct Qdisc, q_rcu);

 	const struct Qdisc_ops  *ops = qdisc->ops;
 #ifdef CONFIG_NET_SCHED

@@ -554,7 +550,7 @@ void qdisc_destroy(struct Qdisc *qdisc)

 	if (qdisc->parent)

 		list_del(&qdisc->list);
-	call_rcu(&qdisc->q_rcu, __qdisc_destroy);

+	__qdisc_destroy(qdisc);

 }

 EXPORT_SYMBOL(qdisc_destroy);
--

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