From: Stanislav Fomichev <stfomichev@gmail.com>
To: Jakub Sitnicki <jakub@cloudflare.com>
Cc: bpf@vger.kernel.org, "Alexei Starovoitov" <ast@kernel.org>,
"Arthur Fabre" <arthur@arthurfabre.com>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Jesper Dangaard Brouer" <hawk@kernel.org>,
"Jesse Brandeburg" <jbrandeburg@cloudflare.com>,
"Joanne Koong" <joannelkoong@gmail.com>,
"Lorenzo Bianconi" <lorenzo@kernel.org>,
"Toke Høiland-Jørgensen" <thoiland@redhat.com>,
"Yan Zhai" <yan@cloudflare.com>,
netdev@vger.kernel.org, kernel-team@cloudflare.com,
"Stanislav Fomichev" <sdf@fomichev.me>
Subject: Re: [PATCH bpf-next 07/13] net: Clear skb metadata on handover from device to protocol
Date: Mon, 30 Jun 2025 09:25:41 -0700 [thread overview]
Message-ID: <aGK6hdOwBSC7r4gF@mini-arch> (raw)
In-Reply-To: <20250630-skb-metadata-thru-dynptr-v1-7-f17da13625d8@cloudflare.com>
On 06/30, Jakub Sitnicki wrote:
> With the extension of bpf_dynptr_from_skb(BPF_DYNPTR_F_SKB_METADATA), all
> BPF programs authorized to call this kfunc now have access to the skb
> metadata area.
>
> These programs can read up to skb_shinfo(skb)->meta_len bytes located just
> before skb_mac_header(skb), regardless of what data is currently there.
>
> However, as the network stack processes the skb, headers may be added or
> removed. Hence, we cannot assume that skb_mac_header() always marks the end
> of the metadata area.
>
> To avoid potential pitfalls, reset the skb metadata length to zero before
> passing the skb to the protocol layers. This is a temporary measure until
> we can make metadata persist through protocol processing.
>
> Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
> ---
> net/core/dev.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index be97c440ecd5..4a2389997535 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5839,6 +5839,7 @@ static int __netif_receive_skb_core(struct sk_buff **pskb, bool pfmemalloc,
> }
> #endif
> skb_reset_redirect(skb);
> + skb_metadata_clear(skb);
And the assumption that it's not gonna break the existing cases is
because there is currently no way to read that metadata out afterwards?
next prev parent reply other threads:[~2025-06-30 16:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-30 14:55 [PATCH bpf-next 00/13] Extend skb dynptr for metadata access from TC Jakub Sitnicki
2025-06-30 14:55 ` [PATCH bpf-next 01/13] bpf: Ignore dynptr offset in skb data access Jakub Sitnicki
2025-07-01 20:55 ` Andrii Nakryiko
2025-07-02 8:20 ` Jakub Sitnicki
2025-06-30 14:55 ` [PATCH bpf-next 02/13] bpf: Helpers for skb dynptr read/write/slice Jakub Sitnicki
2025-07-01 2:03 ` kernel test robot
2025-07-01 11:13 ` Jakub Sitnicki
2025-07-01 3:06 ` kernel test robot
2025-06-30 14:55 ` [PATCH bpf-next 03/13] bpf: Add new variant of skb dynptr for the metadata area Jakub Sitnicki
2025-06-30 16:27 ` Stanislav Fomichev
2025-06-30 20:34 ` Jakub Sitnicki
2025-07-01 20:59 ` Andrii Nakryiko
2025-07-02 8:22 ` Jakub Sitnicki
2025-06-30 14:55 ` [PATCH bpf-next 04/13] bpf: Enable read access to skb metadata with bpf_dynptr_read Jakub Sitnicki
2025-06-30 14:55 ` [PATCH bpf-next 05/13] bpf: Enable write access to skb metadata with bpf_dynptr_write Jakub Sitnicki
2025-06-30 14:55 ` [PATCH bpf-next 06/13] bpf: Enable read-write access to skb metadata with dynptr slice Jakub Sitnicki
2025-06-30 14:55 ` [PATCH bpf-next 07/13] net: Clear skb metadata on handover from device to protocol Jakub Sitnicki
2025-06-30 16:25 ` Stanislav Fomichev [this message]
2025-06-30 20:30 ` Jakub Sitnicki
2025-06-30 14:55 ` [PATCH bpf-next 08/13] selftests/bpf: Pass just bpf_map to xdp_context_test helper Jakub Sitnicki
2025-06-30 14:55 ` [PATCH bpf-next 09/13] selftests/bpf: Parametrize test_xdp_context_tuntap Jakub Sitnicki
2025-06-30 14:55 ` [PATCH bpf-next 10/13] selftests/bpf: Cover read access to skb metadata via dynptr Jakub Sitnicki
2025-06-30 14:55 ` [PATCH bpf-next 11/13] selftests/bpf: Cover write " Jakub Sitnicki
2025-06-30 14:55 ` [PATCH bpf-next 12/13] selftests/bpf: Cover lack of access to skb metadata at ip layer Jakub Sitnicki
2025-06-30 14:55 ` [PATCH bpf-next 13/13] selftests/bpf: Count successful bpf program runs 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=aGK6hdOwBSC7r4gF@mini-arch \
--to=stfomichev@gmail.com \
--cc=arthur@arthurfabre.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=jakub@cloudflare.com \
--cc=jbrandeburg@cloudflare.com \
--cc=joannelkoong@gmail.com \
--cc=kernel-team@cloudflare.com \
--cc=kuba@kernel.org \
--cc=lorenzo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sdf@fomichev.me \
--cc=thoiland@redhat.com \
--cc=yan@cloudflare.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.