[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9aa1f2b0-0f63-45e8-b787-e14d53cac75a@linux.dev>
Date: Thu, 17 Jul 2025 17:06:21 -0700
From: Martin KaFai Lau <martin.lau@...ux.dev>
To: Jakub Sitnicki <jakub@...udflare.com>
Cc: Alexei Starovoitov <ast@...nel.org>, Andrii Nakryiko <andrii@...nel.org>,
Arthur Fabre <arthur@...hurfabre.com>, Daniel Borkmann
<daniel@...earbox.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Jesper Dangaard Brouer <hawk@...nel.org>,
Jesse Brandeburg <jbrandeburg@...udflare.com>,
Joanne Koong <joannelkoong@...il.com>, Lorenzo Bianconi
<lorenzo@...nel.org>, Toke Høiland-Jørgensen
<thoiland@...hat.com>, Yan Zhai <yan@...udflare.com>,
kernel-team@...udflare.com, netdev@...r.kernel.org,
Stanislav Fomichev <sdf@...ichev.me>, bpf@...r.kernel.org
Subject: Re: [PATCH bpf-next v2 01/13] bpf: Add dynptr type for skb metadata
On 7/16/25 9:16 AM, Jakub Sitnicki wrote:
> +__bpf_kfunc int bpf_dynptr_from_skb_meta(struct __sk_buff *skb, u64 flags,
> + struct bpf_dynptr *ptr__uninit)
> +{
> + return dynptr_from_skb_meta(skb, flags, ptr__uninit, false);
> +}
> +
> __bpf_kfunc int bpf_dynptr_from_xdp(struct xdp_md *x, u64 flags,
> struct bpf_dynptr *ptr__uninit)
> {
> @@ -12165,8 +12190,15 @@ int bpf_dynptr_from_skb_rdonly(struct __sk_buff *skb, u64 flags,
> return 0;
> }
>
> +int bpf_dynptr_from_skb_meta_rdonly(struct __sk_buff *skb, u64 flags,
> + struct bpf_dynptr *ptr__uninit)
> +{
> + return dynptr_from_skb_meta(skb, flags, ptr__uninit, true);
> +}
> +
> BTF_KFUNCS_START(bpf_kfunc_check_set_skb)
> BTF_ID_FLAGS(func, bpf_dynptr_from_skb, KF_TRUSTED_ARGS)
> +BTF_ID_FLAGS(func, bpf_dynptr_from_skb_meta, KF_TRUSTED_ARGS)
I looked at the high level of the set. I have a quick question.
Have you considered to create another bpf_kfunc_check_set_xxx that is only for
the tc and tracing prog type? No need to expose this kfunc to other prog types
if the skb_meta is not available now at those hooks.
It seems patch 5 is to ensure other prog types has meta_len 0 and some of the
tests are to ensure that the other prog types cannot do useful things with the
new skb_meta kfunc. The tests will also be different eventually when the
skb_meta can be preserved beyond tc.
Powered by blists - more mailing lists