On Tue, Dec 1, 2015 at 8:34 AM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Tue, 2015-12-01 at 17:13 +0100, PaX Team wrote: >> On 1 Dec 2015 at 6:10, Eric Dumazet wrote: >> >> > On Tue, 2015-12-01 at 06:06 -0800, Eric Dumazet wrote: >> > > On Tue, 2015-12-01 at 12:19 +0100, Daniele Fucini wrote: >> > > > Thanks for the reply. Here's the output of `tc qdisc show`: >> > > > https://gist.github.com/1847102c8fe08f63e9e7 >> > >> > > Hmm... I do not think we ever took care of MQ in >> > > qdisc_tree_decrease_qlen() >> > >> > This looks like a false positive, because MQ recomputes backlog/qlen at >> > the time (stats) dumps are requested. >> > >> > I would say there is no bug. >> >> is it correct for sk_buff_head.qlen to underflow in general >> or just in this particular sched code? (we can exclude overflow >> checking for either case but obviously would like to retain as >> much coverage as possible) > > We do not particularly care on the qlen value for MQ, although we simply > should avoid doing anything. > > Otherwise we might report slightly wrong qlen values while doing "tc -s > qdisc show" if the qdisc_tree_decrease_qlen() happens right after we > computed the folded values in mq_dump() > > Please try the patch I sent. I am pretty sure it should be the right > fix. >
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)? -- 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
