From: David Miller <davem@davemloft.net>
Date: Sun, 17 Aug 2008 15:57:23 -0700 (PDT)

quoted text
> From: Jarek Poplawski <jarkao2@gmail.com>
> Date: Thu, 14 Aug 2008 08:52:50 +0000
> 
> > On the other hand... such a flag would be probably for one thing only.
> > And if we would have a "netif_scheduled_without_xmitting" counter this
> > could probably make 2 in 1?
> 
> Here is how I propose to plug this hole.  The issue is that there is
> this potential gap where both bits are clear while there is a context
> that can reschedule the qdisc.

My apologies Jarek, this is largely identical to a patch you posted
already.  Sorry :(

I thought about it some more, but there is still the dev_queue_xmit()
context that can have a reference to the old qdisc, be about to take
the qdisc lock and feed packets into it's ->enqueue().

That's why we need the RCU destruction still.  dev_deactivate() really
doesn't clear out all references to the qdisc fully.

It might be a better approach to work on making that simply not matter,
and just rely on RCU or similar to defer destruction and any real state
changes internally to the qdisc tree will simply use the root qdisc's
lock to block out enqueue/dequeue/requeue calls.

In that kind of scheme dev_deactivate() just sets the RCU pointer and
doesn't sit around waiting for anything.
--
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