On Wed, 2 Jun 2021 09:21:01 +0800 Yunsheng Lin wrote: > >> For the MISSING clearing in pfifo_fast_dequeue(), it seems it > >> looks like the data race described in RFC v3 too? > >> > >> CPU1 CPU2 CPU3 > >> qdisc_run_begin(q) . . > >> . MISSED is set . > >> MISSED is cleared . . > >> q->dequeue() . . > >> . enqueue skb1 check MISSED # true > >> qdisc_run_end(q) . . > >> . . qdisc_run_begin(q) # true > >> . MISSED is set send skb2 directly > > > > Not sure what you mean. > > CPU1 CPU2 CPU3 > qdisc_run_begin(q) . . > . MISSED is set . > MISSED is cleared . . > another dequeuing . . > . . . > . enqueue skb1 nolock_qdisc_is_empty() # true > qdisc_run_end(q) . . > . . qdisc_run_begin(q) # true > . . send skb2 directly > . MISSED is set . > > As qdisc is indeed empty at the point when MISSED is clear and > another dequeue is retried by CPU1, MISSED setting is not under > q->seqlock, so it seems retesting MISSED under q->seqlock does not > seem to make any difference? and it seems like the case that does > not need handling as we agreed previously? Right, this case doesn't need the re-check under the lock, but pointed out that the re-queuing case requires the re-check.
