netdev - Re: tuntap: Overload handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1361122998.19353.86.camel@edumazet-glaptop>
Date:	Sun, 17 Feb 2013 09:43:18 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	Sebastian Pöhn 
	<sebastian.poehn@...glemail.com>, netdev@...r.kernel.org
Subject: Re: tuntap: Overload handling

On Sun, 2013-02-17 at 15:24 +0200, Michael S. Tsirkin wrote:

> But, userspace is in no position to decide whether using
> the qdisc is a good or a bad thing.
> The issue I tried to solve is that with tun, it's trivially easy for
> userspace to lock up resources forever.
> Simply not stopping the qdisc is probably the simplest solution.
> 
> An alternative is to orphan the skbs before we queue them.
> At some point I posted a proposal doing exactly this
> subj of "net: orphan queued skbs if device tx can stall".
> Do you think it's worth revisiting this?

Its trivially easy for userspace to consume all resources, with or
without tuntap.

Say, a regular Gbps ethernet device.

We need some flow control at some point, unless we deal with device
with unlimited bandwidth.

If we orphan skbs too soon, how can we limit a single sender to flood
the device ? Even a single TCP flow could do that. TCP Small Queues
prevent this, but relies on proper skb orphaning.

If the tuntap problem is that skb can sit there and are never consumed,
its not a bug in the producer (the sender), but a problem with the
receiver (the consumer of the queue). Some kind of cleanup is needed.

Lets take the qdisc analogy :

Codel for instance is able to drop packets that are sitting too long in
queue. skbs are not orphaned until they are freed.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html