Re: [PATCH net-next v3 0/9] tunnels: add core and gre drop reasons

On Wed, Sep 16, 2026 at 7:37 AM Anton Danilov
[off-list ref] wrote:

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.

This is not correct, and it is the justification the whole series rests on.
kfree_skb() is a one line wrapper, from include/linux/skbuff.h:
static inline void kfree_skb(struct sk_buff *skb)
{
        kfree_skb_reason(skb, SKB_DROP_REASON_NOT_SPECIFIED);
}

Both spellings hit the same trace_kfree_skb tracepoint. These packets are
already visible to perf trace -e skb:kfree_skb and are already reported by
drop_monitor today. They just carry reason=NOT_SPECIFIED.
It goes further than that. The tracepoint also carries the call site:
TRACE_EVENT(kfree_skb,
        TP_PROTO(struct sk_buff *skb, void *location,
                 enum skb_drop_reason reason, const struct sock *rx_sk),
drop_monitor's summary mode aggregates on exactly that (trace_drop_common()
keys on point->pc), and packet mode exports it as NET_DM_ATTR_PC plus an
in-kernel resolved NET_DM_ATTR_SYMBOL. So userspace gets
"ip_tunnel_rcv+0x1a4" for each of these drops without any of your patches.
That is how tunnel drops have been triaged since well before drop reasons
existed.

A consequence worth noticing: several of the kfree_skb() ->
kfree_skb_reason(skb, SKB_DROP_REASON_NOT_SPECIFIED) conversions in patch 3
are no-ops.

Now, I am not objecting to the series. I am objecting to the argument,
because the real one is better and you are not making it:

Every failure in these functions funnels into a single drop: / tx_error: /
err_free_skb: label. So "location" is one program counter for all of them.

Four distinct failures in ip_tunnel_rcv(), around twenty in ip_gre's
transmit path, eighty across the series, all collapsing into one bucket.

Call site attribution, which is the pre-drop-reason fallback, tells you
nothing here. On top of that the pc is not a stable interface: it moves with
compiler version, inlining and config, so it cannot be used for filtering or
for comparing across kernels, while NET_DM_ATTR_REASON and BPF filtering on
the reason field can.

Please rewrite the cover letter and the individual changelogs along those
lines. Several of them repeat the "invisible" wording.