All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: netdev@vger.kernel.org
Cc: Phil Sutter <phil@nwl.cc>, Robert Olsson <robert@herjulf.se>,
	Jamal Hadi Salim <jhs@mojatatu.com>,
	Jesper Dangaard Brouer <brouer@redhat.com>
Subject: [net-next PATCH 3/3] qdisc: catch misconfig of attaching qdisc to tx_queue_len zero device
Date: Thu, 03 Nov 2016 14:56:11 +0100	[thread overview]
Message-ID: <20161103135611.28737.39840.stgit@firesoul> (raw)
In-Reply-To: <20161103135534.28737.37657.stgit@firesoul>

It is a clear misconfiguration to attach a qdisc to a device with
tx_queue_len zero, because some qdisc's (namely, pfifo, bfifo, gred,
htb, plug and sfb) inherit/copy this value as their queue length.

Why should the kernel catch such a misconfiguration?  Because prior to
introducing the IFF_NO_QUEUE device flag, userspace found a loophole
in the qdisc config system that allowed them to achieve the equivalent
of IFF_NO_QUEUE, which is to remove the qdisc code path entirely from
a device.  The loophole on older kernels is setting tx_queue_len=0,
*prior* to device qdisc init (the config time is significant, simply
setting tx_queue_len=0 doesn't trigger the loophole).

This loophole is currently used by Docker[1] to get better performance
and scalability out of the veth device.  The Docker developers were
warned[1] that they needed to adjust the tx_queue_len if ever
attaching a qdisc.  The OpenShift project didn't remember this warning
and attached a qdisc, this were caught and fixed in[2].

[1] https://github.com/docker/libcontainer/pull/193
[2] https://github.com/openshift/origin/pull/11126

Instead of fixing every userspace program that used this loophole, and
forgot to reset the tx_queue_len, prior to attaching a qdisc.  Let's
catch the misconfiguration on the kernel side.

Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
 net/sched/sch_api.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index 206dc24add3a..f337f1bdd1d4 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -960,6 +960,17 @@ static struct Qdisc *qdisc_create(struct net_device *dev,
 
 	sch->handle = handle;
 
+	/* This exist to keep backward compatible with a userspace
+	 * loophole, what allowed userspace to get IFF_NO_QUEUE
+	 * facility on older kernels by setting tx_queue_len=0 (prior
+	 * to qdisc init), and then forgot to reinit tx_queue_len
+	 * before again attaching a qdisc.
+	 */
+	if ((dev->priv_flags & IFF_NO_QUEUE) && (dev->tx_queue_len == 0)) {
+		dev->tx_queue_len = DEFAULT_TX_QUEUE_LEN;
+		netdev_info(dev, "Caught tx_queue_len zero misconfig\n");
+	}
+
 	if (!ops->init || (err = ops->init(sch, tca[TCA_OPTIONS])) == 0) {
 		if (qdisc_is_percpu_stats(sch)) {
 			sch->cpu_bstats =

  parent reply	other threads:[~2016-11-03 13:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-03 13:55 [net-next PATCH 0/3] qdisc and tx_queue_len cleanups for IFF_NO_QUEUE devices Jesper Dangaard Brouer
2016-11-03 13:56 ` [net-next PATCH 1/3] net: make default TX queue length a defined constant Jesper Dangaard Brouer
2016-11-03 13:56 ` [net-next PATCH 2/3] net/qdisc: IFF_NO_QUEUE drivers should use consistent TX queue len Jesper Dangaard Brouer
2016-11-03 20:54   ` Krister Johansen
2016-11-04 10:56     ` Jesper Dangaard Brouer
2016-11-03 13:56 ` Jesper Dangaard Brouer [this message]
2016-11-04  9:35   ` [net-next PATCH 3/3] qdisc: catch misconfig of attaching qdisc to tx_queue_len zero device Phil Sutter
2016-11-04 10:10     ` Jesper Dangaard Brouer
2016-11-04 10:59       ` Phil Sutter
2016-11-04 12:09         ` Jesper Dangaard Brouer
2016-11-04 12:53   ` Sergei Shtylyov
2016-11-08  6:14   ` Maciej Żenczykowski
2016-11-08  7:46     ` Jesper Dangaard Brouer
2016-11-07 18:13 ` [net-next PATCH 0/3] qdisc and tx_queue_len cleanups for IFF_NO_QUEUE devices David Miller
2016-11-07 20:11   ` Jesper Dangaard Brouer
2016-11-08  1:16 ` David Miller

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=20161103135611.28737.39840.stgit@firesoul \
    --to=brouer@redhat.com \
    --cc=jhs@mojatatu.com \
    --cc=netdev@vger.kernel.org \
    --cc=phil@nwl.cc \
    --cc=robert@herjulf.se \
    /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.