From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed2-f35.google.com (mail-ed2-f35.google.com [74.125.228.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 209B14A2622 for ; Thu, 24 Sep 2026 16:52:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.228.99 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790268757; cv=none; b=sSBDqByEhnWSblCz01XoRov4MQCpXp7dSwFABq83Kq/PgAmryPy5L9mSEEU5jtfTBLimCmqZlU0wm3p8rjjdnas3SnAxpwTMc48i4mCl2aAinzsQyqGDooIhA9J1JJWW5tckSPrdqm93igcX2jHPv5clinbXEkUnM8KKd1JU69c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790268757; c=relaxed/simple; bh=zajOpfpBg5ymkn/Jim8bbUW8GjfWWdYrue2j1pBz1T8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=J0Fjl6UM0RbDY79j8Lf61sUlidXlFFPPhcKcOj+dZBcCuFuzQBRvoqY00rab7uCTYDWAelY3Dmzg/l1OC7c+Z/yRhjYaU26HH0gAPMsghwhpAlr+hBcNfPHecowK6zbNPdtX+tqvn7y+a2lSdhq3FPbplXU00iZ6LMOB8oFfS6c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cloudflare.com; spf=pass smtp.mailfrom=cloudflare.com; dkim=pass (2048-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b=f7Yue0/q; arc=none smtp.client-ip=74.125.228.99 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cloudflare.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cloudflare.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b="f7Yue0/q" Received: by mail-ed2-f35.google.com with SMTP id 4fb4d7f45d1cf-6aa1d00daaaso126908a12.1 for ; Thu, 24 Sep 2026 09:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1790268754; x=1790873554; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :user-agent:references:in-reply-to:subject:cc:to:from:from:to:cc :subject:date:message-id:reply-to:content-type; bh=5ZgnWusXCU12zGzkWVjE72AKIB7phfrZXuIevy8gML4=; b=f7Yue0/qpeOInQp8bQpMhoJku1geFlUAPGz6JBPNi7FmjlOKjKTWuezqjX5X46OkHd oVBseXyLUF/eL/JRuuTA6pZBwZB+Yq5OqD4EExGzHirhBcsKEX1awlt53lzzRCycm76E K9rLbztJfLNVvgFQ8IG5bRlWNRvBlZwaIIts8TR1pvSyJqI7kLGkMW7wEmuE91yDP7EE NYCymrMnQffqABOFBBEwwDGcVqfW8LYS+e6taZOjK/VDNfdtClxLK7MirgQqR82B7T5x qZcCkXoZT5eG3hFxcjBdTyWm71TVD5SpRb61p6qxDMfveP3KsVC4qI4cSga16aWALnX3 lsdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790268754; x=1790873554; h=content-transfer-encoding:content-type:mime-version:message-id:date :user-agent:references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=5ZgnWusXCU12zGzkWVjE72AKIB7phfrZXuIevy8gML4=; b=uQVEzU0c000BsYV6nwmrNAwJ/WJcY2L7CfaEN1kMie1KcWUihsHOpJlEAKWIpyVVb2 FAjPy3oAnSP1Fbh3qq24UM2fqp5J6BtOGM9pkI0kzwGyaNcjk40z6gg6AoPlvIeUAX3u sLB/rCIqnX/en0kbDu3e0P7Pu4ptCmXnonr7J16GWFEe0HJqW1i1MehCkNhzhINeTvYv stMWK/OnoClog15Dqzey+etZmw8KuWF1zhUVCcRyplENC9zTFFJOALncpOv6T6oJ/55g TnWig5ApF9iQi9G3KrG5uRXATE0q87GuQSpeXTHGVotapHsf53oOpJ4b8SsOF3HmsQRC cxBw== X-Gm-Message-State: AFuF++kXVUv7lE+6fAd1tNYrah7i6XwTOhEhIlWLjNv9nknxUUy0Iu6D W2GYBVKOUPm7STxeKg3uMznDHQ2J4zAlNbN31d4j7wN8T6hurOyprhMVSt2Mn12ihn8= X-Gm-Gg: AYBFou0aAM9h6jj0//UA+cpXSoy1F3XI5JCkv1HcWBI/XddGOnpsIUaV9GCNV8/7ciI qQE/ebYXxwByUkeKwjapHWcntBQOBNx5yf5IcHqEGL3v9CZ+9+3YpGONw9VSpWw8JpqSxI5FW7A oSHfkGkxxtg1158HYquot0Jw8rk4x6+qNz93AC18ca1NEMOpEZZkyPw1xZbHHalP12qLrzJ2HSM JKUsQnZQ8xBJF/ZsbQjJBf4shsS2IvrdAYPmwm6pkFhjttVW68cR9IH5Ahild4KHyxa2JiMECpx bEUU5FKusNqGjvwx2/Uh+QhA3/+nX0Gz0icmsq7oIea4eAXvAOjAXfan9Z0TP3k39ax9fGPcZsS nJxPQ8SILGsE1UW1naXxqKluElbEzyiSn4Nll6UCn32BxQWOO7X9I4UQMpXfgG7gVMYtuGimVXQ EdidrxADJYkSH9PQllVdMSUBHbSpBHP1xib3mlabhxdh02WUgKromh3TX/ubYQo12DZdr8K/X1r Y52FdDeHuU= X-Received: by 2002:a05:6402:52c1:b0:6aa:1d41:628 with SMTP id 4fb4d7f45d1cf-6aac8ecf666mr2384920a12.7.1790268754290; Thu, 24 Sep 2026 09:52:34 -0700 (PDT) Received: from cloudflare.com ([104.28.21.182]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6aae3a9924asm37248a12.30.2026.09.24.09.52.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Sep 2026 09:52:33 -0700 (PDT) From: Jakub Sitnicki To: "Daniel Zahka" Cc: , "Alexei Starovoitov" , "Jakub Kicinski" , "Kuniyuki Iwashima" , "Paolo Abeni" , "Stanislav Fomichev" , , , "Daniel Borkmann" , "John Fastabend" , "Andrii Nakryiko" , "Eduard Zingerman" , "Kumar Kartikeya Dwivedi" , "Martin KaFai Lau" , "Song Liu" , "Yonghong Song" , "Jiri Olsa" , "Emil Tsalapatis" , "David S. Miller" , "Eric Dumazet" , "Simon Horman" , "Jesper Dangaard Brouer" , "Willem de Bruijn" , "Florian Westphal" , "Jack Wang" <163wangjack@gmail.com> Subject: Re: [PATCH net-next v2 03/14] bpf: Make BPF skb extension survive packet scrubbing In-Reply-To: (Daniel Zahka's message of "Wed, 23 Sep 2026 13:46:28 -0400") References: <20260910-bpf-meta-inside-skb-ext-v2-0-0b21e42180b0@cloudflare.com> <20260910-bpf-meta-inside-skb-ext-v2-3-0b21e42180b0@cloudflare.com> User-Agent: mu4e 1.14.1; emacs 30.2 Date: Thu, 24 Sep 2026 18:52:32 +0200 Message-ID: <87fqyypp67.fsf@cloudflare.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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_scru= b() >> 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_ud= p() >> would take the __consume_stateless_skb() fast path, which skips >> skb_release_head_state(), and leak the extension slab. >> >> Signed-off-by: Jakub Sitnicki >> --- > > 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 =C2=B1 3.16** | **+8.01 =C2=B1 4.75** | | sys | +2.62 =C2=B1 2.06 | +3.67 =C2=B1 2.76 | | soft | +2.89 =C2=B1 1.43 | +3.83 =C2=B1 2.10 | | ns/pkt @146k pps | **+=E2=89=88 373** | **+=E2=89=88 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-0= 9-24/ [2] https://lpc.events/event/20/contributions/2549/