Thread (28 messages) flat view 28 messages, 5 authors, 1d ago

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/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help