netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin KaFai Lau <martin.lau@linux.dev>
To: Jakub Sitnicki <jakub@cloudflare.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Simon Horman <horms@kernel.org>,
	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>,
	bpf@vger.kernel.org, netdev@vger.kernel.org,
	kernel-team@cloudflare.com
Subject: Re: [PATCH bpf-next v2 11/15] selftests/bpf: Expect unclone to preserve skb metadata
Date: Wed, 22 Oct 2025 16:12:39 -0700	[thread overview]
Message-ID: <2753c96b-48f9-480e-923c-60d2c20ebb03@linux.dev> (raw)
In-Reply-To: <20251019-skb-meta-rx-path-v2-11-f9a58f3eb6d6@cloudflare.com>



On 10/19/25 5:45 AM, Jakub Sitnicki wrote:
> @@ -447,12 +448,14 @@ int clone_dynptr_empty_on_meta_slice_write(struct __sk_buff *ctx)
>   
>   /*
>    * Check that skb_meta dynptr is read-only before prog writes to packet payload
> - * using dynptr_write helper. Applies only to cloned skbs.
> + * using dynptr_write helper, and becomes read-write afterwards. Applies only to
> + * cloned skbs.
>    */
>   SEC("tc")
> -int clone_dynptr_rdonly_before_data_dynptr_write(struct __sk_buff *ctx)
> +int clone_dynptr_rdonly_before_data_dynptr_write_then_rw(struct __sk_buff *ctx)
>   {
>   	struct bpf_dynptr data, meta;
> +	__u8 meta_have[META_SIZE];
>   	const struct ethhdr *eth;
>   
>   	bpf_dynptr_from_skb(ctx, 0, &data);
> @@ -465,15 +468,23 @@ int clone_dynptr_rdonly_before_data_dynptr_write(struct __sk_buff *ctx)
>   
>   	/* Expect read-only metadata before unclone */
>   	bpf_dynptr_from_skb_meta(ctx, 0, &meta);
> -	if (!bpf_dynptr_is_rdonly(&meta) || bpf_dynptr_size(&meta) != META_SIZE)
> +	if (!bpf_dynptr_is_rdonly(&meta))

Can the bpf_dynptr_set_rdonly() be lifted from the 
bpf_dynptr_from_skb_meta()?

iiuc, the remaining thing left should be handling a cloned skb in 
__bpf_dynptr_write()? The __bpf_skb_store_bytes() is using 
bpf_try_make_writable, so maybe something similar can be done for the 
BPF_DYNPTR_TYPE_SKB_META?

> +		goto out;
> +
> +	bpf_dynptr_read(meta_have, META_SIZE, &meta, 0, 0);
> +	if (!check_metadata(meta_have))
>   		goto out;
>   
>   	/* Helper write to payload will unclone the packet */
>   	bpf_dynptr_write(&data, offsetof(struct ethhdr, h_proto), "x", 1, 0);
>   
> -	/* Expect no metadata after unclone */
> +	/* Expect r/w metadata after unclone */
>   	bpf_dynptr_from_skb_meta(ctx, 0, &meta);
> -	if (bpf_dynptr_is_rdonly(&meta) || bpf_dynptr_size(&meta) != 0)
> +	if (bpf_dynptr_is_rdonly(&meta))

then it does not have to rely on the bpf_dynptr_write(&data, ...) above 
to make the metadata writable.

I have a high level question about the set. I assume the skb_data_move() 
in patch 2 will be useful in the future to preserve the metadata across 
the stack. Preserving the metadata across different tc progs (which this 
set does) is nice to have but it is not the end goal. Can you shed some 
light on the plan for building on top of this set?

  reply	other threads:[~2025-10-22 23:12 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
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 [this message]
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=2753c96b-48f9-480e-923c-60d2c20ebb03@linux.dev \
    --to=martin.lau@linux.dev \
    --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=kuba@kernel.org \
    --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).