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]

Date:	Sun, 17 Feb 2013 15:24:04 +0200
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Sebastian Pöhn 
	<sebastian.poehn@...glemail.com>, netdev@...r.kernel.org
Subject: Re: tuntap: Overload handling

On Thu, Feb 14, 2013 at 09:01:30AM -0800, Eric Dumazet wrote:
> On Thu, 2013-02-14 at 18:42 +0200, Michael S. Tsirkin wrote:
> 
> > Hmm so ~1000 packets in the tun queue is not enough?
> > You always have the option to increase it some more ...
> > 
> > > You should ask Michael S. Tsirkin, as he removed the flow control
> > > in commit 5d097109257c03a71845729f8db6b5770c4bbedc
> > > (tun: only queue packets on device)
> > > 
> > 
> > Eric in the past you said the following things
> > (http://lkml.indiana.edu/hypermail/linux/kernel/1204.1/00784.html)
> > > > In your case I would just not use qdisc at all, like other virtual
> > > > devices.
> > ...
> > > > Anyway, with a 500 packet limit in TUN queue itself, qdisc layer should
> > > > be always empty. Whats the point storing more than 500 packets for a
> > > > device ? Thats a latency killer.
> > you don't think this applies, anymore?
> > 
> 
> Users have the choice to setup a qdisc or not.
> 
> Having no qdisc can help raw performance, at the expense of bufferbloat.
> Thats all I was saying.
> 
> It seems tun.c has no longer the possibility to effectively use a qdisc,
> (allowing the queue to buildup at qdisc layer)
> 

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?

Also - does anyone know of a testcase showing there's a problem
with the simplest solution we now have in place?

-- 
MST
--
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