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

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Thu Sep 24, 2026 at 4:52 PM UTC, Jakub Sitnicki wrote:
> 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.

Well, the numbers speak for themselves. I think :)