Re: [PATCH net-next v2 03/14] bpf: Make BPF skb extension survive packet scrubbing

[Jakub Sitnicki <jakub@cloudflare.com>]

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:
>> 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/