netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Herbert Xu <herbert@gondor.hengli.com.au>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	"Jamal Hadi Salim" <hadi@cyberus.ca>,
	"Stephen Hemminger" <shemminger@vyatta.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Neil Horman" <nhorman@tuxdriver.com>,
	"Jiri Pirko" <jpirko@redhat.com>,
	"Jeff Kirsher" <jeffrey.t.kirsher@intel.com>,
	"Eric Dumazet" <eric.dumazet@gmail.com>,
	"Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
	"Ben Hutchings" <bhutchings@solarflare.com>
Subject: Re: [PATCH] net: orphan queued skbs if device tx can stall
Date: Mon, 9 Apr 2012 10:28:49 +0300	[thread overview]
Message-ID: <20120409072849.GA12014@redhat.com> (raw)
In-Reply-To: <20120408234951.GA15993@gondor.apana.org.au>

On Mon, Apr 09, 2012 at 07:49:51AM +0800, Herbert Xu wrote:
> On Sun, Apr 08, 2012 at 08:13:25PM +0300, Michael S. Tsirkin wrote:
> > commit 0110d6f22f392f976e84ab49da1b42f85b64a3c5
> > tun: orphan an skb on tx
> > Fixed a configuration where skbs get queued
> > at the tun device forever, blocking senders.
> > 
> > However this fix isn't waterproof:
> > userspace can control whether the interface
> > is stopped, and if it is, packets
> > get queued in the qdisc, again potentially forever.
> > 
> > Complete the fix by setting a private flag and orphaning
> > at the qdisc level.
> > 
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> 
> 1) Doesn't this break local UDP push-back?

What is meant by UDP pushback here? Two tap
devices communicating by UDP packets locally?
This was always broken, see below.

> 2) Isn't the stall a bug in the backend and isn't this just
> papering over that?
> 
> Cheers,

What do you mean by the backend? userspace? Yes, the stall is a result of
userspace not consuming packets:

        if (skb_queue_len(&tun->socket.sk->sk_receive_queue) >= dev->tx_queue_len) {
                if (!(tun->flags & TUN_ONE_QUEUE)) {
                        /* Normal queueing mode. */
                        /* Packet scheduler handles dropping of further packets. */
                        netif_stop_queue(dev);
                       /* We won't see all dropped packets individually, so overrun
                         * error is more appropriate. */
                        dev->stats.tx_fifo_errors++;

Thus we get this situation
    tap1 sends packets, some of them to tap2, tap2 does not consume them,
    as a result tap2 queue overflows, tap2 stops forever and
    packets get queued in the qdisc, now tap1
    send buffer gets full so it can not communicate to any destination.

So the problem is one VM can block all networking from another one.

As a solution this patch is always changing ownership if we're going
into a hostile device: it just does this early in qdisc instead of
at xmit time.



> -- 
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

  reply	other threads:[~2012-04-09  7:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-08 17:13 [PATCH] net: orphan queued skbs if device tx can stall Michael S. Tsirkin
2012-04-08 23:49 ` Herbert Xu
2012-04-09  7:28   ` Michael S. Tsirkin [this message]
2012-04-09  7:33     ` Herbert Xu
2012-04-09  7:39       ` Michael S. Tsirkin
2012-04-09  8:29         ` Herbert Xu
2012-04-09  8:34           ` Michael S. Tsirkin
2012-04-09  8:39             ` Herbert Xu
2012-04-09  8:42               ` Michael S. Tsirkin
2012-04-09  9:13                 ` Eric Dumazet
2012-04-10  7:55 ` Eric Dumazet
2012-04-10  8:41   ` Michael S. Tsirkin
2012-04-10  8:55     ` Eric Dumazet
2012-04-10  9:31       ` Michael S. Tsirkin
2012-04-10 10:04         ` Eric Dumazet
2012-04-10 11:25           ` Michael S. Tsirkin
2012-04-10 11:45             ` Eric Dumazet
2012-04-10 12:41               ` Michael S. Tsirkin
2012-04-10 13:52                 ` Eric Dumazet
2012-04-10 14:10                   ` Michael S. Tsirkin
2012-04-11 21:52                   ` Michael S. Tsirkin
2012-05-08 19:35                   ` Michael S. Tsirkin
2012-05-08 19:50                   ` Michael S. Tsirkin

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=20120409072849.GA12014@redhat.com \
    --to=mst@redhat.com \
    --cc=bhutchings@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=hadi@cyberus.ca \
    --cc=herbert@gondor.hengli.com.au \
    --cc=jasowang@redhat.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jpirko@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mirq-linux@rere.qmqm.pl \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=shemminger@vyatta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).