From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH RFC 2/2] veth: propagate bridge GSO to peer Date: Thu, 30 Nov 2017 09:49:32 -0800 Message-ID: <20171130094932.6d9e7c61@xeon-e3> References: <20171126181749.19288-1-sthemmin@microsoft.com> <20171126181749.19288-3-sthemmin@microsoft.com> <20171126230725.1fcc3b51@xeon-e3> <20171127201419.GA79@intel.com> <20171127131502.1fbfaa66@xeon-e3> <20171128014222.GA503@intel.com> <91628267-2e48-a231-7cc2-4830eb95ceef@gmail.com> <20171130003534.GA60@intel.com> <20171130091021.658869b0@xeon-e3> <1512062799.19682.19.camel@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Solio Sarabia , David Ahern , davem@davemloft.net, netdev@vger.kernel.org, sthemmin@microsoft.com, shiny.sebastian@intel.com To: Eric Dumazet Return-path: Received: from mail-pl0-f65.google.com ([209.85.160.65]:36240 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753655AbdK3Rtk (ORCPT ); Thu, 30 Nov 2017 12:49:40 -0500 Received: by mail-pl0-f65.google.com with SMTP id b12so4679520plm.3 for ; Thu, 30 Nov 2017 09:49:40 -0800 (PST) In-Reply-To: <1512062799.19682.19.camel@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: On Thu, 30 Nov 2017 09:26:39 -0800 Eric Dumazet wrote: > On Thu, 2017-11-30 at 09:10 -0800, Stephen Hemminger wrote: > >=20 > >=20 > > The problem goes back into the core GSO networking code. > > Something like this is needed. > >=20 > > static inline bool netif_needs_gso(struct sk_buff *skb, > > =C2=A0=C2=A0=C2=A0const struct net_device *dev, > > =C2=A0=C2=A0=C2=A0netdev_features_t features) > > { > > return skb_is_gso(skb) && > > (!skb_gso_ok(skb, features) || > > =C2=A0unlikely(skb_shinfo(skb)->gso_segs > dev- =20 > > >gso_max_segs) ||=C2=A0=C2=A0<< new =20 > > =C2=A0unlikely(skb_shinfo(skb)->gso_size > dev- =20 > > >gso_max_size) ||=C2=A0=C2=A0<< new =20 > > =C2=A0unlikely((skb->ip_summed !=3D CHECKSUM_PARTIAL) && > > =C2=A0=C2=A0(skb->ip_summed !=3D CHECKSUM_UNNECESSARY))); > > } > >=20 > > 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. =20 >=20 >=20 > 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: =46rom 71a134f41c4aae8947241091300d21745aa237f2 Mon Sep 17 00:00:00 2001 From: Stephen Hemminger 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 --- 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 st= ruct sk_buff *skb, struct net_device *dev, netdev_features_t features) { + unsigned int gso_size =3D skb_shinfo(skb)->gso_size; u16 gso_segs =3D skb_shinfo(skb)->gso_segs; =20 - 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; =20 /* Support for GSO partial features requires software --=20 2.11.0