Re: [PATCH net-next v2 03/14] bpf: Make BPF skb extension survive packet scrubbing
From: Jakub Sitnicki <jakub@cloudflare.com>
Date: 2026-09-24 16:52:36
Also in:
bpf
Hi Daniel, On Wed, Sep 23, 2026 at 01:46 PM -04, Daniel Zahka wrote:
On Thu Sep 10, 2026 at 10:02 AM EDT, Jakub Sitnicki wrote:quoted
skb_scrub_packet() drops all skb extensions unconditionally via skb_ext_reset(). It runs on tunnel encap/decap (ip_tunnel_rcv, vxlan_rcv, etc.) and cross-netns forwarding (dev_forward_skb). This makes it impossible for a BPF program to pass metadata via bpf_skb_ext through a tunnel or across a netns boundary. The extension is always lost at the scrub point. Introduce skb_ext_scrub(), a selective variant of skb_ext_reset(). It deletes every extension except SKB_EXT_BPF. Scrubbing is safe when the extension slab is shared with clones: deleting an extension only clears the per-skb active_extensions bit, and the shared slab payload is released lazily by __skb_ext_put() once the last reference goes away. Replace the skb_ext_reset() call in skb_scrub_packet() with skb_ext_scrub() and also switch udp_try_make_stateless() to skb_ext_scrub() as well, so the BPF metadata survives queueing onto a UDP socket receive queue and stays readable there (e.g. for a sockmap verdict program). Only mark the skb stateless when no extension survives the scrub. Otherwise skb_consume_udp() would take the __consume_stateless_skb() fast path, which skips skb_release_head_state(), and leak the extension slab. Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com> ---Hello Jakub, What are your current plans for this series? This commit solves the same problem I have with wanting to preserve the PSP skb extension across netns forwarding.
I've implemented Alexei's idea of skb-lifecycle tracepoints that run only when an skb is marked/traced. Currently putting final touches on it before sending it out for the first round of feedback. You can take sneak peek at it on GH [1] to see if it meets your needs. The CPU overhead is lower compared to the skb extension, at least in my local runs, and the kernel changes are simpler, so it seems like a win overall: | | gated skb tps | bpf skb ext | |------------------|------------------|------------------| | **busy** | **+5.44 ± 3.16** | **+8.01 ± 4.75** | | sys | +2.62 ± 2.06 | +3.67 ± 2.76 | | soft | +2.89 ± 1.43 | +3.83 ± 2.10 | | ns/pkt @146k pps | **+≈ 373** | **+≈ 549** | I'll be giving an update on it at LPC [1], if you're attending, and of course will keep you posted here on the ML. -jkbs [1] https://github.com/jsitnicki/linux/commits/gated-skb-tracepoints-2026-09-24/ [2] https://lpc.events/event/20/contributions/2549/