From: Jakub Kicinski <kuba@kernel.org>
To: Jakub Sitnicki <jakub@cloudflare.com>
Cc: bpf@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Daniel Borkmann <daniel@iogearbox.net>,
John Fastabend <john.fastabend@gmail.com>,
Stanislav Fomichev <sdf@fomichev.me>,
Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
KP Singh <kpsingh@kernel.org>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>,
Arthur Fabre <arthur@arthurfabre.com>,
netdev@vger.kernel.org, kernel-team@cloudflare.com
Subject: Re: [PATCH bpf-next v2 01/15] net: Preserve metadata on pskb_expand_head
Date: Thu, 23 Oct 2025 17:51:19 -0700 [thread overview]
Message-ID: <20251023175119.62785270@kernel.org> (raw)
In-Reply-To: <20251019-skb-meta-rx-path-v2-1-f9a58f3eb6d6@cloudflare.com>
On Sun, 19 Oct 2025 14:45:25 +0200 Jakub Sitnicki wrote:
> pskb_expand_head() copies headroom, including skb metadata, into the newly
> allocated head, but then clears the metadata. As a result, metadata is lost
> when BPF helpers trigger an skb head reallocation.
True, then again if someone is reallocating headroom they may very well
push a header after, shifting metadata into an uninitialized part of
the headroom. Not sure we can do much about that, but perhaps worth
being more explicit in the commit msg?
next prev parent reply other threads:[~2025-10-24 0:51 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-19 12:45 [PATCH bpf-next v2 00/15] Make TC BPF helpers preserve skb metadata Jakub Sitnicki
2025-10-19 12:45 ` [PATCH bpf-next v2 01/15] net: Preserve metadata on pskb_expand_head Jakub Sitnicki
2025-10-24 0:51 ` Jakub Kicinski [this message]
2025-10-24 12:17 ` Jakub Sitnicki
2025-10-19 12:45 ` [PATCH bpf-next v2 02/15] net: Helper to move packet data and metadata after skb_push/pull Jakub Sitnicki
2025-10-19 12:45 ` [PATCH bpf-next v2 03/15] vlan: Make vlan_remove_tag return nothing Jakub Sitnicki
2025-10-19 12:45 ` [PATCH bpf-next v2 04/15] bpf: Make bpf_skb_vlan_pop helper metadata-safe Jakub Sitnicki
2025-10-19 12:45 ` [PATCH bpf-next v2 05/15] bpf: Make bpf_skb_vlan_push " Jakub Sitnicki
2025-10-19 12:45 ` [PATCH bpf-next v2 06/15] bpf: Make bpf_skb_adjust_room metadata-safe Jakub Sitnicki
2025-10-19 12:45 ` [PATCH bpf-next v2 07/15] bpf: Make bpf_skb_change_proto helper metadata-safe Jakub Sitnicki
2025-10-19 12:45 ` [PATCH bpf-next v2 08/15] bpf: Make bpf_skb_change_head " Jakub Sitnicki
2025-10-19 12:45 ` [PATCH bpf-next v2 09/15] selftests/bpf: Verify skb metadata in BPF instead of userspace Jakub Sitnicki
2025-10-19 12:45 ` [PATCH bpf-next v2 10/15] selftests/bpf: Dump skb metadata on verification failure Jakub Sitnicki
2025-10-22 23:30 ` Martin KaFai Lau
2025-10-23 10:38 ` Jakub Sitnicki
2025-10-19 12:45 ` [PATCH bpf-next v2 11/15] selftests/bpf: Expect unclone to preserve skb metadata Jakub Sitnicki
2025-10-22 23:12 ` Martin KaFai Lau
2025-10-23 11:55 ` Jakub Sitnicki
2025-10-24 2:32 ` Martin KaFai Lau
2025-10-24 15:40 ` Jakub Sitnicki
2025-10-19 12:45 ` [PATCH bpf-next v2 12/15] selftests/bpf: Cover skb metadata access after vlan push/pop helper Jakub Sitnicki
2025-10-19 12:45 ` [PATCH bpf-next v2 13/15] selftests/bpf: Cover skb metadata access after bpf_skb_adjust_room Jakub Sitnicki
2025-10-19 12:45 ` [PATCH bpf-next v2 14/15] selftests/bpf: Cover skb metadata access after change_head/tail helper Jakub Sitnicki
2025-10-19 12:45 ` [PATCH bpf-next v2 15/15] selftests/bpf: Cover skb metadata access after bpf_skb_change_proto Jakub Sitnicki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251023175119.62785270@kernel.org \
--to=kuba@kernel.org \
--cc=andrii@kernel.org \
--cc=arthur@arthurfabre.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=eddyz87@gmail.com \
--cc=edumazet@google.com \
--cc=haoluo@google.com \
--cc=horms@kernel.org \
--cc=jakub@cloudflare.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kernel-team@cloudflare.com \
--cc=kpsingh@kernel.org \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).