Re: [PATCH net-next v4 00/10] tunnels: add core and gre drop reasons

[Ido Schimmel <idosch@nvidia.com>]

On Wed, Sep 23, 2026 at 01:14:57AM +0300, Anton Danilov wrote:
> Only vxlan reports drop reasons among the tunnel drivers today. The ones
> converted here free what they drop with kfree_skb(), which drop_monitor
> and the skb:kfree_skb tracepoint do report, but as NOT_SPECIFIED, with
> the call site as the only hint at which check failed. That hint does not
> go far: all the failures of ip_tunnel_rcv() end at one call site, and so
> do nearly all of those of each transmit function. The call site is not a
> stable interface either: its offset moves with the compiler, inlining
> and the configuration, so a filter on it has to follow every rebuild.
> The reason stays the same across kernels, whether NET_DM_ATTR_REASON
> reports it or a BPF program matches it by name. The device counters
> group the failures coarsely too: rx_errors and tx_errors each lump
> together unrelated conditions.
> 
> This series covers the generic paths shared by ipip, sit, gre and their
> IPv6 counterparts, plus the GRE specific code, in both directions.
> A later series will do the same for geneve, bareudp, fou and the
> remaining IP in IP drivers.

Please only annotate drivers that you are familiar with, using and can
test. Otherwise it's a burden on the reviewer and potentially useless
code churn that will make it harder to backport future fixes.

> 
> 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, like TCP_OLD_SEQUENCE for TCP
> 
> 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 the peer's numbers get past the last one the receiver
> accepted. By the counters alone that looks like a misconfiguration: a
> packet without the sequence number option bumps the same rx_fifo_errors.
> 
> Patches 3-6 convert the GRE specific receive path. gre_parse_header()
> returns -EINVAL for every failure, 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. gre_parse_header() now returns
> a drop reason instead, and its callers take the header length from
> tpi->hdr_len. The receive helpers below gre_rcv() return the drop reason
> instead of a PACKET_* code, and the PACKET_* codes go away. Three
> reasons are added: GRE_INVALID_HDR and GRE_TUNNEL_NOT_FOUND, mirroring
> vxlan's VXLAN_INVALID_HDR and VXLAN_VNI_NOT_FOUND, and GRE_CSUM, like
> TCP_CSUM and UDP_CSUM.

GRE_CSUM looks fine as I'm not aware of other tunnels that have a
dedicated checksum, but GRE_INVALID_HDR and GRE_TUNNEL_NOT_FOUND should
be renamed to something more generic (e.g., TUNNEL_INVALID_HDR and
TUNNEL_NOT_FOUND) so that they could be reused across drivers and
replace the existing VXLAN ones. Note that you don't need the drop
reason to encode the tunnel name in order to know which tunnel driver
dropped the packet.

> 
> Patch 4 adds __iptunnel_pull_header_reason(), because
> __iptunnel_pull_header() reports a packet too short to pull as -ENOMEM,
> the same as an allocation failure, and ip6_gre calls it for every GRE
> packet, before the tunnel lookup.

The series is inconsistent about this and returns different reasons
(HDR_TRUNC / PKT_TOO_SMALL) for the same condition. I suggest that you
convert pskb_may_pull() to pskb_may_pull_reason() and return its reason
instead of HDR_TRUNC.