All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"David S. Miller" <davem@davemloft.net>,
	Herbert Xu <herbert@gondor.hengli.com.au>,
	Paul Moore <paul.moore@hp.com>,
	David Woodhouse <David.Woodhouse@intel.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [PATCH] tun: orphan an skb on tx
Date: Tue, 13 Apr 2010 23:43:07 +0300	[thread overview]
Message-ID: <20100413204307.GC3582@redhat.com> (raw)
In-Reply-To: <1271191086.16881.570.camel@edumazet-laptop>

On Tue, Apr 13, 2010 at 10:38:06PM +0200, Eric Dumazet wrote:
> Le mardi 13 avril 2010 à 23:25 +0300, Michael S. Tsirkin a écrit :
> > On Tue, Apr 13, 2010 at 08:31:03PM +0200, Eric Dumazet wrote:
> > > Le mardi 13 avril 2010 à 20:39 +0300, Michael S. Tsirkin a écrit :
> > > 
> > > > > When a socket with inflight tx packets is closed, we dont block the
> > > > > close, we only delay the socket freeing once all packets were delivered
> > > > > and freed.
> > > > > 
> > > > 
> > > > Which is wrong, since this is under userspace control, so you get
> > > > unkillable processes.
> > > > 
> > > 
> > > We do not get unkillable processes, at least with sockets I was thinking
> > > about (TCP/UDP ones).
> > > 
> > > Maybe tun sockets can behave the same ?
> > 
> > Looks like that's what my patch does: ip_rcv seems to call
> > skb_orphan too.
> 
> Well, I was speaking of tx side, you speak of receiving side.

Point is, both ip_rcv and my patch call skb_orphan.

> An external flood (coming from another domain) is another problem.
> 
> A sender might flood the 'network' inside our domain. How can we
> reasonably limit the sender ?
> 
> Maybe the answer is 'We can not', but it should be stated somewhere, so
> that someone can address this point later.
> 

And whatever's done should ideally work for tap to IP
and IP to IP sockets as well, not just tap to tap.

-- 
MST

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Paul Moore <paul.moore@hp.com>,
	David Woodhouse <David.Woodhouse@intel.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	Herbert Xu <herbert@gondor.hengli.com.au>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>
Subject: [Qemu-devel] Re: [PATCH] tun: orphan an skb on tx
Date: Tue, 13 Apr 2010 23:43:07 +0300	[thread overview]
Message-ID: <20100413204307.GC3582@redhat.com> (raw)
In-Reply-To: <1271191086.16881.570.camel@edumazet-laptop>

On Tue, Apr 13, 2010 at 10:38:06PM +0200, Eric Dumazet wrote:
> Le mardi 13 avril 2010 à 23:25 +0300, Michael S. Tsirkin a écrit :
> > On Tue, Apr 13, 2010 at 08:31:03PM +0200, Eric Dumazet wrote:
> > > Le mardi 13 avril 2010 à 20:39 +0300, Michael S. Tsirkin a écrit :
> > > 
> > > > > When a socket with inflight tx packets is closed, we dont block the
> > > > > close, we only delay the socket freeing once all packets were delivered
> > > > > and freed.
> > > > > 
> > > > 
> > > > Which is wrong, since this is under userspace control, so you get
> > > > unkillable processes.
> > > > 
> > > 
> > > We do not get unkillable processes, at least with sockets I was thinking
> > > about (TCP/UDP ones).
> > > 
> > > Maybe tun sockets can behave the same ?
> > 
> > Looks like that's what my patch does: ip_rcv seems to call
> > skb_orphan too.
> 
> Well, I was speaking of tx side, you speak of receiving side.

Point is, both ip_rcv and my patch call skb_orphan.

> An external flood (coming from another domain) is another problem.
> 
> A sender might flood the 'network' inside our domain. How can we
> reasonably limit the sender ?
> 
> Maybe the answer is 'We can not', but it should be stated somewhere, so
> that someone can address this point later.
> 

And whatever's done should ideally work for tap to IP
and IP to IP sockets as well, not just tap to tap.

-- 
MST

  reply	other threads:[~2010-04-13 20:48 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-13 14:59 [PATCH] tun: orphan an skb on tx Michael S. Tsirkin
2010-04-13 14:59 ` [Qemu-devel] " Michael S. Tsirkin
2010-04-13 15:12 ` Herbert Xu
2010-04-13 15:12   ` [Qemu-devel] " Herbert Xu
2010-04-13 15:12   ` Herbert Xu
2010-04-13 15:36 ` Jan Kiszka
2010-04-13 15:36   ` [Qemu-devel] " Jan Kiszka
2010-04-13 16:40   ` Eric Dumazet
2010-04-13 16:40     ` [Qemu-devel] " Eric Dumazet
2010-04-13 16:52     ` Jan Kiszka
2010-04-13 16:52       ` [Qemu-devel] " Jan Kiszka
2010-04-13 17:39     ` Michael S. Tsirkin
2010-04-13 17:39       ` [Qemu-devel] " Michael S. Tsirkin
2010-04-13 18:31       ` Eric Dumazet
2010-04-13 18:31         ` [Qemu-devel] " Eric Dumazet
2010-04-13 20:25         ` Michael S. Tsirkin
2010-04-13 20:25           ` [Qemu-devel] " Michael S. Tsirkin
2010-04-13 20:38           ` Eric Dumazet
2010-04-13 20:38             ` [Qemu-devel] " Eric Dumazet
2010-04-13 20:43             ` Michael S. Tsirkin [this message]
2010-04-13 20:43               ` Michael S. Tsirkin
2010-04-14  0:58         ` Herbert Xu
2010-04-14  0:58           ` [Qemu-devel] " Herbert Xu
2010-04-14  0:58           ` Herbert Xu
2010-04-14 11:55           ` David Miller
2010-04-14 11:55             ` [Qemu-devel] " David Miller
2010-04-14 11:55             ` David Miller
2015-02-01 11:20           ` David Woodhouse
2015-02-01 11:20             ` [Qemu-devel] " David Woodhouse
2015-02-01 12:26             ` Michael S. Tsirkin
2015-02-01 12:26               ` [Qemu-devel] " Michael S. Tsirkin
2015-02-01 13:33               ` David Woodhouse
2015-02-01 13:33                 ` [Qemu-devel] " David Woodhouse
2015-02-01 20:19                 ` David Miller
2015-02-01 20:19                   ` [Qemu-devel] " David Miller
2015-02-01 21:29                   ` David Woodhouse
2015-02-01 21:29                     ` [Qemu-devel] " David Woodhouse
2015-02-02  5:07                     ` David Miller
2015-02-02  5:07                       ` [Qemu-devel] " David Miller
2015-02-02  5:07                       ` David Miller
2015-02-02  7:27                       ` David Woodhouse
2015-02-02  7:27                         ` [Qemu-devel] " David Woodhouse
2015-02-02  8:24                         ` Steffen Klassert
2015-02-02  8:24                           ` [Qemu-devel] " Steffen Klassert
2015-02-02 15:30                           ` David Woodhouse
2015-02-02 15:30                             ` [Qemu-devel] " David Woodhouse
2015-02-02 15:23                         ` Phil Sutter
2015-02-02 15:23                           ` [Qemu-devel] " Phil Sutter
2015-02-02 15:47                           ` David Woodhouse
2015-02-02 15:47                             ` [Qemu-devel] " David Woodhouse
2015-02-04  0:19                         ` David Miller
2015-02-04  0:19                           ` [Qemu-devel] " David Miller
2015-02-04  6:35                           ` David Woodhouse
2015-02-04  6:35                             ` [Qemu-devel] " David Woodhouse
2021-06-25 15:56                       ` Bringing the SSL VPN data path back in-kernel David Woodhouse
2010-04-21 11:35 ` [PATCH] tun: orphan an skb on tx Michael S. Tsirkin
2010-04-21 11:35   ` [Qemu-devel] " Michael S. Tsirkin
2010-04-21 11:46   ` Jan Kiszka
2010-04-21 11:46     ` [Qemu-devel] " Jan Kiszka
2010-04-21 11:45     ` Michael S. Tsirkin
2010-04-21 11:45       ` [Qemu-devel] " Michael S. Tsirkin
2010-04-21 19:16   ` [stable] " Greg KH
2010-04-21 19:16     ` [Qemu-devel] " Greg KH
2010-09-14 15:20 ` 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=20100413204307.GC3582@redhat.com \
    --to=mst@redhat.com \
    --cc=David.Woodhouse@intel.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=herbert@gondor.hengli.com.au \
    --cc=jan.kiszka@siemens.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=paul.moore@hp.com \
    --cc=qemu-devel@nongnu.org \
    /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.