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

[Jakub Sitnicki <jakub@cloudflare.com>]

On Fri, Sep 25, 2026 at 08:03 AM -04, Daniel Zahka wrote:
> On Thu Sep 24, 2026 at 12:52 PM EDT, 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.
>>
>> -jkbs
>>
>> [1] https://github.com/jsitnicki/linux/commits/gated-skb-tracepoints-2026-09-24/
>> [2] https://lpc.events/event/20/contributions/2549/
>
> Very cool. Thanks for sharing. So it seems your new approach will not
> use skb extensions, and this commit will go away :(
>
> I still have a need for this behavior of persisting certain skb
> extensions through scrubbing. I haven't considered all of my options
> yet, but I suspect the approach in this commit will work basically as
> is. If you are going to abandon this commit, would you be ok if I
> included it in a series of my own for PSP? I would, of course, leave you
> as the commit author, or give you whatever other form attribution you
> prefer.

Ah, I see now. I thought for a moment we were talking about extracting
some PSP state and passing it using BPF metadata.

Feel free to reuse & remix. I think it's enough if you link to the
original posting.