netdev - Re: [PATCH RFC 2/2] veth: propagate bridge GSO to peer

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:   Thu, 30 Nov 2017 10:08:25 -0800
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     Solio Sarabia <solio.sarabia@...el.com>,
        David Ahern <dsahern@...il.com>, davem@...emloft.net,
        netdev@...r.kernel.org, sthemmin@...rosoft.com,
        shiny.sebastian@...el.com
Subject: Re: [PATCH RFC 2/2] veth: propagate bridge GSO to peer

On Thu, 30 Nov 2017 09:59:23 -0800
Eric Dumazet <eric.dumazet@...il.com> wrote:

> On Thu, 2017-11-30 at 09:49 -0800, Stephen Hemminger wrote:
> > On Thu, 30 Nov 2017 09:26:39 -0800
> > Eric Dumazet <eric.dumazet@...il.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@...rosoft.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@...rosoft.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  
> 
> 
> Yes, but check commit 743b03a83297690f0bd38c452a3bbb47d2be300a
> ("net: remove netdevice gso_min_segs")
> 
> Plan was to get rid of the existing check, not adding new ones :/

Sure can do it in the driver and that has other benefits like ability
to backport to older distributions.

Still need gso_max_size though since want to tell TCP to avoid
generating mega-jumbo frames.