netdev - Re: [PATCH] net: orphan queued skbs if device tx can stall

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: <20120409073354.GA3218@gondor.apana.org.au>
Date:	Mon, 9 Apr 2012 15:33:54 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	Jamal Hadi Salim <hadi@...erus.ca>,
	Stephen Hemminger <shemminger@...tta.com>,
	Jason Wang <jasowang@...hat.com>,
	Neil Horman <nhorman@...driver.com>,
	Jiri Pirko <jpirko@...hat.com>,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Michał Mirosław <mirq-linux@...e.qmqm.pl>,
	Ben Hutchings <bhutchings@...arflare.com>
Subject: Re: [PATCH] net: orphan queued skbs if device tx can stall

On Mon, Apr 09, 2012 at 10:28:49AM +0300, Michael S. Tsirkin wrote:
>
> > 1) Doesn't this break local UDP push-back?
> 
> What is meant by UDP pushback here? Two tap
> devices communicating by UDP packets locally?
> This was always broken, see below.

I mean push-back from UDP transmission to the physical NIC.

Your patch breaks that as now the guest will have no push-back
whatsoever so anything that transmits UDP without protocol-level
congestion control will start dropping most of their packets.

Granted you can argue that these apps are broken, but they do
exist and we've always catered for them, both on baremetal and
under virtualisation.
 
> Thus we get this situation
>     tap1 sends packets, some of them to tap2, tap2 does not consume them,
>     as a result tap2 queue overflows, tap2 stops forever and
>     packets get queued in the qdisc, now tap1
>     send buffer gets full so it can not communicate to any destination.
> 
> So the problem is one VM can block all networking from another one.

This should be addressed in the backend, as it can distinguish
between packets going out to physical and packets stuck going to
a local VM.  In the latter case you can then duplicate and release
the sender's memory.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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