[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CALrw=nEdA0asN4n7B3P2TyHKJ+UBPvoAiMrwkT42=fqp2-CPiw@mail.gmail.com>
Date: Fri, 1 Mar 2019 12:19:07 +0000
From: Ignat Korchagin <ignat@...udflare.com>
To: netdev@...r.kernel.org
Cc: Daniel Dao <dqminh@...udflare.com>,
Ivan Babrou <ivan@...udflare.com>,
Frank Hofmann <fhofmann@...udflare.com>,
Nicolae Vartolomei <nv@...udflare.com>
Subject: noqueue qdisc and non-virtual interfaces
Good day,
According to this link:
http://linux-tc-notes.sourceforge.net/tc/doc/sch_noqueue.txt it should
not be possible to assign noqueue qdisc to physical devices or
classes. Yet, I can clearly do it even on the latest 5.0-rc series
kernels:
$ sudo tc qdisc add dev eth0 root noqueue
$ sudo tc qdisc show dev eth0
qdisc noqueue 8005: root refcnt 385
If I understand the source correctly, noqueue qdisc was designed only
for network interfaces, which have IFF_NO_QUEUE in priv_flags in
net_device structure. However, I see no checks in the code, which
enforce it when attaching this qdisc to an interface.
I believe, it was not possible before, but commit
d66d6c3152e8d5a6db42a56bf7ae1c6cae87ba48 changed that.
Regardless, if it is intentional or not, the change is incomplete as
it introduces a potential NULL ptr dereference bug, which can be
triggered by doing something like:
dev="eth0"
sudo tc qdisc replace dev $dev root noqueue
sudo tc qdisc delete dev $dev root
sudo tc qdisc replace dev $dev root handle 1: htb default 1
sudo tc class add dev $dev parent 1: classid 1:1 htb rate 1000Gbps
sudo tc qdisc add dev $dev parent 1:1 handle 10: noqueue
I believe it should not be possible to have noqueue qdisc on physical
nics, but, please, let me know if I'm wrong.
Regards,
Ignat
Powered by blists - more mailing lists