All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ignat Korchagin <ignat@cloudflare.com>
To: netdev@vger.kernel.org
Cc: Daniel Dao <dqminh@cloudflare.com>,
	Ivan Babrou <ivan@cloudflare.com>,
	Frank Hofmann <fhofmann@cloudflare.com>,
	Nicolae Vartolomei <nv@cloudflare.com>
Subject: noqueue qdisc and non-virtual interfaces
Date: Fri, 1 Mar 2019 12:19:07 +0000	[thread overview]
Message-ID: <CALrw=nEdA0asN4n7B3P2TyHKJ+UBPvoAiMrwkT42=fqp2-CPiw@mail.gmail.com> (raw)

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

                 reply	other threads:[~2019-03-01 12:19 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALrw=nEdA0asN4n7B3P2TyHKJ+UBPvoAiMrwkT42=fqp2-CPiw@mail.gmail.com' \
    --to=ignat@cloudflare.com \
    --cc=dqminh@cloudflare.com \
    --cc=fhofmann@cloudflare.com \
    --cc=ivan@cloudflare.com \
    --cc=netdev@vger.kernel.org \
    --cc=nv@cloudflare.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.