Those comments are out of date and I need to update them.
In fact this whole loop is now largely pointless.
The rcu_dereference() on dev_queue->qdisc happens before the
QDISC_RUNNING bit is set.
We no longer resample the qdisc under any kind of lock. Because we no
longer have a top-level lock that synchronizes the setting of
dev_queue->qdisc
Rather, the lock we use for calling ->enqueue() and ->dequeue() is
inside of the root qdisc itself.
That's why all of the real destruction has to occur in the RCU handler.
Anyways, this is part of the problem I think is causing the crash the
Intel folks are triggering.
We sample the qdisc in dev_queue_xmit() or wherever, then we attach
that to the per-cpu ->output_queue to process it via qdisc_run()
in the software interrupt handler.
The RCU quiesce period extends to the next scheduling point and this
is enough if we do normal direct softirq processing of this qdisc.
But if it gets postponed into ksoftirqd... the RCU will pass too
early.
I'm still thinking about how to fix this without avoiding RCU
and without adding new synchronization primitives.
--
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