All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Solio Sarabia <solio.sarabia@intel.com>,
	David Ahern <dsahern@gmail.com>,
	davem@davemloft.net, netdev@vger.kernel.org,
	sthemmin@microsoft.com, shiny.sebastian@intel.com
Subject: Re: [PATCH RFC 2/2] veth: propagate bridge GSO to peer
Date: Thu, 30 Nov 2017 09:49:32 -0800	[thread overview]
Message-ID: <20171130094932.6d9e7c61@xeon-e3> (raw)
In-Reply-To: <1512062799.19682.19.camel@gmail.com>

On Thu, 30 Nov 2017 09:26:39 -0800
Eric Dumazet <eric.dumazet@gmail.com> wrote:

> On Thu, 2017-11-30 at 09:10 -0800, Stephen Hemminger wrote:
> > 
> > 
> > The problem goes back into the core GSO networking code.
> > Something like this is needed.
> > 
> > static inline bool netif_needs_gso(struct sk_buff *skb,
> > 				   const struct net_device *dev,
> > 				   netdev_features_t features)
> > {
> > 	return skb_is_gso(skb) &&
> > 		(!skb_gso_ok(skb, features) ||
> > 		 unlikely(skb_shinfo(skb)->gso_segs > dev-  
> > >gso_max_segs) ||  << new  
> > 		 unlikely(skb_shinfo(skb)->gso_size > dev-  
> > >gso_max_size) ||  << new  
> > 		 unlikely((skb->ip_summed != CHECKSUM_PARTIAL) &&
> > 			  (skb->ip_summed != CHECKSUM_UNNECESSARY)));
> > }
> > 
> > What that will do is split up the monster GSO packets if they ever
> > bleed
> > across from one device to another through the twisty mazes of packet
> > processing paths.  
> 
> 
> Since very few drivers have these gso_max_segs / gso_max_size, check
> could be done in their ndo_features_check()

Actually, we already check for max_segs, just missing check for size here:

From 71a134f41c4aae8947241091300d21745aa237f2 Mon Sep 17 00:00:00 2001
From: Stephen Hemminger <sthemmin@microsoft.com>
Date: Thu, 30 Nov 2017 09:45:11 -0800
Subject: [PATCH] net: do not GSO if frame is too large

This adds an additional check to breakup skb's that exceed a devices
GSO maximum size. The code was already checking for too many segments
but did not check size.

This has been observed to be a problem when using containers on
Hyper-V/Azure where the allowed GSO maximum size is less than
maximum and skb's have gone through multiple layers to arrive
at the virtual device.

Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
 net/core/dev.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 07ed21d64f92..0bb398f3bfa3 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2918,9 +2918,11 @@ static netdev_features_t gso_features_check(const struct sk_buff *skb,
 					    struct net_device *dev,
 					    netdev_features_t features)
 {
+	unsigned int gso_size = skb_shinfo(skb)->gso_size;
 	u16 gso_segs = skb_shinfo(skb)->gso_segs;
 
-	if (gso_segs > dev->gso_max_segs)
+	if (gso_segs > dev->gso_max_segs ||
+	    gso_size > dev->gso_max_size)
 		return features & ~NETIF_F_GSO_MASK;
 
 	/* Support for GSO partial features requires software
-- 
2.11.0

  parent reply	other threads:[~2017-11-30 17:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-26 18:17 [PATCH RFC 0/2] veth, bridge, and GSO maximums Stephen Hemminger
2017-11-26 18:17 ` [PATCH RFC 1/2] br: add notifier for when bridge changes it " Stephen Hemminger
2017-11-26 18:17 ` [PATCH RFC 2/2] veth: propagate bridge GSO to peer Stephen Hemminger
2017-11-27  3:13   ` David Ahern
2017-11-27  7:07     ` Stephen Hemminger
2017-11-27 20:14       ` Solio Sarabia
2017-11-27 21:15         ` Stephen Hemminger
2017-11-28  1:42           ` Solio Sarabia
2017-11-28  2:02             ` David Ahern
2017-11-30  0:35               ` Solio Sarabia
2017-11-30 17:10                 ` Stephen Hemminger
2017-11-30 17:26                   ` Eric Dumazet
2017-11-30 17:36                     ` Stephen Hemminger
2017-11-30 17:38                     ` David Miller
2017-11-30 17:49                     ` Stephen Hemminger [this message]
2017-11-30 17:59                       ` Eric Dumazet
2017-11-30 18:08                         ` Stephen Hemminger
2017-11-30 18:10                           ` Eric Dumazet
2017-12-01 20:30               ` Stephen Hemminger
2017-11-30 15:47 ` [PATCH RFC 0/2] veth, bridge, and GSO maximums David Miller
2017-11-30 17:11   ` Stephen Hemminger
2017-11-30 20:50     ` Alexander Duyck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171130094932.6d9e7c61@xeon-e3 \
    --to=stephen@networkplumber.org \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=shiny.sebastian@intel.com \
    --cc=solio.sarabia@intel.com \
    --cc=sthemmin@microsoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.