On Tue 17 Sep 2019 at 20:03, Cong Wang <xiyou.wangcong@xxxxxxxxx> wrote:
> On Tue, Sep 17, 2019 at 1:27 AM Vlad Buslov <vladbu@xxxxxxxxxxxx> wrote:
>> Hi Cong,
>>
>> Don't see why we would need qdisc tree lock while releasing the
>> reference to (or destroying) previous Qdisc. I've skimmed through other
>> scheds and it looks like sch_multiq, sch_htb and sch_tbf are also
>> affected. Do you want me to send patches?
>
> Yes, please do.
It looks like tbf is not affected by the bug after all. Relevant part of
code from tbf_change():
if (q->qdisc != &noop_qdisc) {
err = fifo_set_limit(q->qdisc, qopt->limit);
if (err)
goto done;
} else if (qopt->limit > 0) {
child = fifo_create_dflt(sch, &bfifo_qdisc_ops, qopt->limit,
extack);
if (IS_ERR(child)) {
err = PTR_ERR(child);
goto done;
}
/* child is fifo, no need to check for noop_qdisc */
qdisc_hash_add(child, true);
}
sch_tree_lock(sch);
if (child) {
qdisc_tree_flush_backlog(q->qdisc);
qdisc_put(q->qdisc);
q->qdisc = child;
}
It seems that qdisc_put() is redundant here because it is only called
q->qdisc == &noop_qdisc, which is a noop.
|