| 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
| ||
|
Date: Mon, 21 Jul 2014 08:54:20 +0200 From: Florian Westphal <fw@...len.de> To: David Miller <davem@...emloft.net> Cc: fw@...len.de, netdev@...r.kernel.org Subject: Re: [PATCH -next] tun: stop tx queue when limit is hit David Miller <davem@...emloft.net> wrote: > From: Florian Westphal <fw@...len.de> > Date: Sun, 20 Jul 2014 20:51:25 +0200 > > > Currently tun just frees the skb and returns NETDEV_TX_OK > > when queue length exceeds txqlen. > > > > This causes severe packetloss and unneeded resource > > consumption on host when sending to vm connected via tun. > > > > Instead, lets stop the transmit queue and start it once > > packets are consumed from the queue. This allows the network > > stack to control applications that send data via tun device. > > I strongly suspect the current behavior is intentional, see > commit: > > commit 5d097109257c03a71845729f8db6b5770c4bbedc > Author: Michael S. Tsirkin <mst@...hat.com> > Date: Mon Dec 3 10:07:14 2012 +0000 > > tun: only queue packets on device Looks like you're right :-/ Alright, please ignore my patch. That being said, the current behaviour isn't ideal either. It took me quite some time to realize that packetloss was on the sender side inside tun driver and not on the receiver vm. Not stopping the queue was a bit ... unexpected. -- 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
Powered by blists - more mailing lists