On Tue, Dec 1, 2015 at 11:09 AM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Tue, 2015-12-01 at 10:43 -0800, Cong Wang wrote: > >> This smells hacky... Another way to fix this is to hold the qdisc tree >> lock in mq_dump(), since it is not a hot path (comparing with >> enqueue/dequeue)? > > Really ? Which qdisc tree lock will protect you exactly ??? > > Whole point of MQ is that each TX queue has its own lock. > > So multiple cpus can call qdisc_tree_decrease_qlen() at the same time, > holding their own lock. > > Clearly modifying mq 'data' is wrong.
Ah, yeah, but mq _seems_ also the only one who modifies sch->q.qlen in ->dump(), which is the root cause of this bug. I am wondering if it should just compute the qlen and return it without modifying sch->q.qlen. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
