From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Hutchings Subject: Re: [PATCH net 1/2] tcp: Limit number of segments generated by GSO per skb Date: Mon, 30 Jul 2012 20:56:20 +0100 Message-ID: <1343678180.2667.37.camel@bwh-desktop.uk.solarflarecom.com> References: <1343668498.2667.5.camel@bwh-desktop.uk.solarflarecom.com> <1343668602.2667.6.camel@bwh-desktop.uk.solarflarecom.com> <1343669507.21269.33.camel@edumazet-glaptop> <1343676952.2667.26.camel@bwh-desktop.uk.solarflarecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: David Miller , , To: Eric Dumazet Return-path: Received: from webmail.solarflare.com ([12.187.104.25]:46912 "EHLO ocex02.SolarFlarecom.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754257Ab2G3T4Y (ORCPT ); Mon, 30 Jul 2012 15:56:24 -0400 In-Reply-To: <1343676952.2667.26.camel@bwh-desktop.uk.solarflarecom.com> Sender: netdev-owner@vger.kernel.org List-ID: On Mon, 2012-07-30 at 20:35 +0100, Ben Hutchings wrote: > On Mon, 2012-07-30 at 19:31 +0200, Eric Dumazet wrote: > > On Mon, 2012-07-30 at 18:16 +0100, Ben Hutchings wrote: > > > A peer (or local user) may cause TCP to use a nominal MSS of as little > > > as 88 (actual MSS of 76 with timestamps). Given that we have a > > > sufficiently prodigious local sender and the peer ACKs quickly enough, > > > it is nevertheless possible to grow the window for such a connection > > > to the point that we will try to send just under 64K at once. This > > > results in a single skb that expands to 861 segments. > > > > > > In some drivers with TSO support, such an skb will require hundreds of > > > DMA descriptors; a substantial fraction of a TX ring or even more than > > > a full ring. The TX queue selected for the skb may stall and trigger > > > the TX watchdog repeatedly (since the problem skb will be retried > > > after the TX reset). This particularly affects sfc, for which the > > > issue is designated as CVE-2012-3412. However it may be that some > > > hardware or firmware also fails to handle such an extreme TSO request > > > correctly. > > > > > > Therefore, limit the number of segments per skb to 100. This should > > > make no difference to behaviour unless the actual MSS is less than > > > about 700. [...] > > An alternative would be to drop such frames in the ndo_start_xmit(), and > > cap sk->sk_gso_max_size (since skb are no longer orphaned...) > > I have implemented that workaround for the out-of-tree version of sfc. > For the in-tree driver, I thought it would be better to limit the number > of segments at source, which will avoid penalising any cases where the > window can grow so much larger than MSS. [...] I mean any *legitimate* cases where this can happen. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked.