All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Danilov <littlesmilingcloud@gmail.com>
To: netdev@vger.kernel.org
Cc: "David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	David Ahern <dsahern@kernel.org>, Simon Horman <horms@kernel.org>,
	Ido Schimmel <idosch@nvidia.com>,
	linux-kernel@vger.kernel.org
Subject: [PATCH net-next v3 0/9] tunnels: add core and gre drop reasons
Date: Wed, 16 Sep 2026 17:37:08 +0300	[thread overview]
Message-ID: <20260916143717.1875082-1-littlesmilingcloud@gmail.com> (raw)

Only vxlan reports drop reasons among the tunnel drivers today.
Everything else, on both the receive and the transmit side, ends in a
plain kfree_skb(), so a packet that a tunnel throws away is invisible
to dropwatch, drop_monitor and perf trace -e skb:kfree_skb. The device
counters group the failures coarsely: rx_errors and tx_errors each
cover half a dozen unrelated conditions.

This series covers the generic paths shared by ipip, sit, gre and their
IPv6 counterparts, plus the GRE specific parsing, on both directions.
A later series will do the same for geneve, bareudp, fou and the
remaining IP in IP drivers.

Patches 1-2 convert the generic receive paths, ip_tunnel_rcv() and
__ip6_tnl_rcv(). Two reasons are added:

  TNL_OPT_MISMATCH  the options a packet carries do not match the
                    tunnel configuration
  TNL_OLD_SEQ       the sequence number is older than the one the
                    tunnel expects, next to the existing
                    TCP_OLD_SEQUENCE

The second one has a failure mode worth naming: when a peer reboots,
its outgoing sequence number restarts at zero and the receiver drops
everything until its own counter catches up. That is indistinguishable
from a misconfiguration by the counters alone.

Patches 3-5 do the GRE specific receive path. gre_parse_header()
returns -EINVAL for six different reasons, and the only detail its
callers could get was a csum_err flag that none of them read: both
ip_gre and ip6_gre declared it, passed it in and ignored it. It is
replaced by a drop reason. Three reasons are added, mirroring vxlan:
GRE_INVALID_HDR, GRE_CSUM and GRE_TUNNEL_NOT_FOUND.

Patches 6-9 do the transmit side, some eighty failure paths across
ip_tunnel, ip_gre, ip6_tunnel and ip6_gre. One reason is added,
TNL_ENCAP, for a failure to build the encapsulation header. Patch 8 is
a small preparation: prepare_ip6gre_xmit_other() cannot fail, so it is
made void rather than given a drop reason for a branch that never runs.

The transmit side has its own case worth naming: tnl_update_pmtu()
returns -E2BIG after it has already sent the ICMP error back, which is
path MTU discovery working exactly as intended, yet the drop lands in
tx_errors next to genuine failures. An MTU black hole cannot be told
from a broken route by looking at the counters.

Drop reasons on transmit are not new: vxlan already reports several
from its xmit path, and ip_tunnel_core.c reports RECURSION_LIMIT.

Changes since v2:
- ipxip6_tnl_xmit() no longer overwrites the reason ip6_tnl_xmit()
  reported: the PKT_TOO_BIG assignment ran for every error, not just
  -EMSGSIZE, and ip6_tnl_xmit() already sets that one itself, so every
  ip4ip6, ip6ip6 and mplsip6 transmit failure was reported as an MTU
  problem
- the NBMA branch of ip6_tnl_xmit() now reports NO_TX_TARGET instead of
  IP_OUTNOROUTES for an skb that carries no destination, matching the
  sibling branch a few lines above and ip_tunnel_xmit()
- the __iptunnel_pull_header() failures now report NOMEM instead of
  HDR_TRUNC: the helper returns -ENOMEM for every failure mode and also
  fails when skb_unclone() cannot allocate, the way vxlan_rcv() labels
  it. The length checks keep HDR_TRUNC
- fixed the call graph in patch 2: the exported ip6_tnl_rcv() is only
  reached from ip6_gre, while ip4ip6, ip6ip6 and mplsip6 come through
  ipxip6_rcv()
- reworded what a NULL reason means for gre_parse_header(): a checksum
  failure is not reported, but the checksum is still computed
- new patch 8: prepare_ip6gre_xmit_other() cannot fail, its only return
  is "return 0", so it is made void and its caller stops checking it.
  v2 attached IPV6_BAD_EXTHDR to that branch, which never runs
- the source address selection of a collect_md tunnel in ip6_tnl_xmit()
  now reports IP_OUTNOROUTES instead of NO_TX_TARGET: the destination
  is known and the route was found, and the IPv6 stack itself treats a
  failed source selection as a failed lookup, the way vxlan reports it
- the commit message of the ip6_tunnel transmit patch now lists every
  reason the patch uses: TNL_ENCAP and UNHANDLED_PROTO were missing and
  RECURSION_LIMIT also covers the address conflict check
- cover letter and commit messages made precise: the transmit side
  labels some eighty failure paths, not forty; vti does not use the
  converted paths; tnl_update_pmtu() returns -E2BIG for IPv6 payloads
  too, not only for IPv4 ones with DF set
- the three selftest patches stay dropped
- v2: https://lore.kernel.org/netdev/20260913034937.875068-1-littlesmilingcloud@gmail.com/
- v1: https://lore.kernel.org/netdev/20260831215137.549324-1-littlesmilingcloud@gmail.com/

Anton Danilov (9):
  ip_tunnel: add drop reasons to the generic RX path
  ip6_tunnel: add drop reasons to the generic RX path
  gre: make gre_parse_header() report a drop reason
  ip_gre: add drop reasons to the RX path
  ip6_gre: add drop reasons to the RX path
  ip_tunnel: add drop reasons to the transmit path
  ip_gre: add drop reasons to the transmit path
  ip6_gre: make prepare_ip6gre_xmit_other() void
  ip6_tunnel: add drop reasons to the transmit path

 include/net/dropreason-core.h |  38 ++++++++
 include/net/gre.h             |   2 +-
 include/net/ip6_tunnel.h      |   3 +-
 net/ipv4/gre_demux.c          |  52 +++++++---
 net/ipv4/ip_gre.c             | 144 +++++++++++++++++++---------
 net/ipv4/ip_tunnel.c          |  60 +++++++++---
 net/ipv6/ip6_gre.c            | 175 +++++++++++++++++++++++-----------
 net/ipv6/ip6_tunnel.c         |  95 +++++++++++++-----
 8 files changed, 419 insertions(+), 150 deletions(-)

-- 
2.47.3


             reply	other threads:[~2026-09-16 14:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-16 14:37 Anton Danilov [this message]
2026-09-16 14:37 ` [PATCH net-next v3 1/9] ip_tunnel: add drop reasons to the generic RX path Anton Danilov
2026-09-16 14:37 ` [PATCH net-next v3 2/9] ip6_tunnel: " Anton Danilov
2026-09-16 14:37 ` [PATCH net-next v3 3/9] gre: make gre_parse_header() report a drop reason Anton Danilov
2026-09-16 14:37 ` [PATCH net-next v3 4/9] ip_gre: add drop reasons to the RX path Anton Danilov
2026-09-16 14:37 ` [PATCH net-next v3 5/9] ip6_gre: " Anton Danilov
2026-09-16 14:37 ` [PATCH net-next v3 6/9] ip_tunnel: add drop reasons to the transmit path Anton Danilov
2026-09-16 14:37 ` [PATCH net-next v3 7/9] ip_gre: " Anton Danilov
2026-09-16 14:37 ` [PATCH net-next v3 8/9] ip6_gre: make prepare_ip6gre_xmit_other() void Anton Danilov
2026-09-16 14:37 ` [PATCH net-next v3 9/9] ip6_tunnel: add drop reasons to the transmit path Anton Danilov
2026-09-16 22:42   ` Jakub Kicinski
2026-09-16 16:27 ` [PATCH net-next v3 0/9] tunnels: add core and gre drop reasons Eric Dumazet

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=20260916143717.1875082-1-littlesmilingcloud@gmail.com \
    --to=littlesmilingcloud@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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.