From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1O1n9G-0005Ne-AQ
	for qemu-devel@nongnu.org; Tue, 13 Apr 2010 16:55:54 -0400
Received: from [140.186.70.92] (port=55071 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1O1n9E-0005AL-Rf
	for qemu-devel@nongnu.org; Tue, 13 Apr 2010 16:55:53 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <mst@redhat.com>) id 1O1n1o-0001tb-M5
	for qemu-devel@nongnu.org; Tue, 13 Apr 2010 16:48:14 -0400
Received: from mx1.redhat.com ([209.132.183.28]:17051)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <mst@redhat.com>) id 1O1n1o-0001tW-E5
	for qemu-devel@nongnu.org; Tue, 13 Apr 2010 16:48:12 -0400
Date: Tue, 13 Apr 2010 23:43:07 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <20100413204307.GC3582@redhat.com>
References: <20100413145944.GA7716@redhat.com> <4BC48F79.5090409@siemens.com>
	<1271176838.16881.537.camel@edumazet-laptop>
	<20100413173919.GC26011@redhat.com>
	<1271183463.16881.545.camel@edumazet-laptop>
	<20100413202548.GA3582@redhat.com>
	<1271191086.16881.570.camel@edumazet-laptop>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <1271191086.16881.570.camel@edumazet-laptop>
Content-Transfer-Encoding: quoted-printable
Subject: [Qemu-devel] Re: [PATCH] tun: orphan an skb on tx
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
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>

On Tue, Apr 13, 2010 at 10:38:06PM +0200, Eric Dumazet wrote:
> Le mardi 13 avril 2010 =E0 23:25 +0300, Michael S. Tsirkin a =E9crit :
> > On Tue, Apr 13, 2010 at 08:31:03PM +0200, Eric Dumazet wrote:
> > > Le mardi 13 avril 2010 =E0 20:39 +0300, Michael S. Tsirkin a =E9cri=
t :
> > >=20
> > > > > When a socket with inflight tx packets is closed, we dont block=
 the
> > > > > close, we only delay the socket freeing once all packets were d=
elivered
> > > > > and freed.
> > > > >=20
> > > >=20
> > > > Which is wrong, since this is under userspace control, so you get
> > > > unkillable processes.
> > > >=20
> > >=20
> > > We do not get unkillable processes, at least with sockets I was thi=
nking
> > > about (TCP/UDP ones).
> > >=20
> > > Maybe tun sockets can behave the same ?
> >=20
> > Looks like that's what my patch does: ip_rcv seems to call
> > skb_orphan too.
>=20
> 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.
>=20
> A sender might flood the 'network' inside our domain. How can we
> reasonably limit the sender ?
>=20
> Maybe the answer is 'We can not', but it should be stated somewhere, so
> that someone can address this point later.
>=20

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

--=20
MST