[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87wm85cnar.fsf@cloudflare.com>
Date: Fri, 18 Jul 2025 21:27:08 +0200
From: Jakub Sitnicki <jakub@...udflare.com>
To: Martin KaFai Lau <martin.lau@...ux.dev>
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 Fri, Jul 18, 2025 at 12:19 PM -07, Martin KaFai Lau wrote:
> On 7/18/25 3:01 AM, Jakub Sitnicki wrote:
>> On Thu, Jul 17, 2025 at 05:06 PM -07, Martin KaFai Lau wrote:
>>> 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
>
> After some more thoughts, lets target it for tc only. I think skb_meta is not
> available in most of the tracepoints now. Lets wait until the skb_meta will be
> supported in other hooks/layers first.
Makes sense. I was planning to drop patch 5 ("net: Clear skb metadata on
handover from device to protocol"), which means
skb_shinfo(skb)->meta_len could be invalid at some tracepoints.
Powered by blists - more mailing lists