All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Duyck <aduyck@mirantis.com>
To: herbert@gondor.apana.org.au, tom@herbertland.com,
	jesse@kernel.org, alexander.duyck@gmail.com, edumazet@google.com,
	netdev@vger.kernel.org, davem@davemloft.net
Subject: [net PATCH v2 0/2] Fixes for GRO and GRE tunnels
Date: Mon, 04 Apr 2016 09:27:53 -0700	[thread overview]
Message-ID: <20160404162545.14332.653.stgit@localhost.localdomain> (raw)

This pair of patches addresses a few issues I have discovered over the last
week or so concerning GRO and GRE tunnels.

The first patch addresses an item I called out as an issue with FOU/GUE
encapsulating GRE, and I finally had a chance to test it and verify that
the code concerning it was broken so I took the opportunity to fix it so
that we cannot generate a FOU/GUE frame that is encapsulating a GRE tunnel
with checksum while requesting TSO/GSO for the frame.

The second patch actually addresses something I realized was an issue if we
feed a tunnel through GRO and back out through GSO.  Specifically it was
possible for GRO to generate overlapping IPv4 ID ranges as the outer IP IDs
were being ignored for tunnels.  Ignoring the IP IDs like this should only
be valid if the DF bit is set.  This is normally the case for IPIP, SIT,
and GRE tunnels, but not so for UDP tunnels.  In the case that the DF bit
is not set we store off the fact that there was a delta from what we were
expecting and when we hit the inner-most header we validate the value as to
avoid generating a frame which could lead to an IP ID collision on packets
that could eventually be fragmented.  A side effect is that the inner-most
IP ID test is relaxed as well, but the worst case scenario is that we GRO a
frame with a throw-away ID sequence anyway so if anything segmenting such a
frame with the wrong IP IDs should have no negative effects.

v2: Updated RFC 6864 patch so that we only support one of two modes.  Either
    the IP ID is incrementing, or it is fixed at a specific value with DF bit
    set.

---

Alexander Duyck (2):
      GRE: Disable segmentation offloads w/ CSUM and we are encapsulated via FOU
      ipv4/GRO: Make GRO conform to RFC 6864


 include/linux/netdevice.h |    5 ++++-
 net/core/dev.c            |    2 ++
 net/ipv4/af_inet.c        |   25 ++++++++++++++++++-------
 net/ipv4/fou.c            |    6 ++++++
 net/ipv4/gre_offload.c    |    8 ++++++++
 net/ipv4/ip_gre.c         |   13 ++++++++++---
 net/ipv6/ip6_offload.c    |    3 ---
 7 files changed, 48 insertions(+), 14 deletions(-)

             reply	other threads:[~2016-04-04 16:28 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-04 16:27 Alexander Duyck [this message]
2016-04-04 16:28 ` [net PATCH v2 1/2] GRE: Disable segmentation offloads w/ CSUM and we are encapsulated via FOU Alexander Duyck
2016-04-04 16:31 ` [net PATCH v2 2/2] ipv4/GRO: Make GRO conform to RFC 6864 Alexander Duyck
2016-04-05  0:38   ` subashab
2016-04-05  3:44   ` Herbert Xu
2016-04-05  4:26     ` Alexander Duyck
2016-04-05  4:32       ` Herbert Xu
2016-04-05 15:07         ` Edward Cree
2016-04-05 15:36           ` Tom Herbert
2016-04-05 17:06             ` Edward Cree
2016-04-05 17:38               ` Tom Herbert
2016-04-06  0:04             ` Marcelo Ricardo Leitner
2016-04-05 23:45           ` David Miller
2016-04-06 11:21             ` Edward Cree
2016-04-06 13:53               ` Tom Herbert
2016-04-06 14:26                 ` Edward Cree
2016-04-06 15:39                   ` Eric Dumazet
2016-04-06 15:55                     ` Edward Cree
2016-04-06 16:03                       ` Eric Dumazet
2016-04-06 15:43                 ` David Miller
2016-04-06 17:42                   ` Tom Herbert
2016-04-06 19:30                     ` David Miller
2016-04-05 15:52         ` Alexander Duyck
2016-04-05 16:30           ` Eric Dumazet
2016-04-05 16:45             ` 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=20160404162545.14332.653.stgit@localhost.localdomain \
    --to=aduyck@mirantis.com \
    --cc=alexander.duyck@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jesse@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=tom@herbertland.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.