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
> 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.
That is a neat idea!
It will let me drop three patches from this series. Let me do that.
Thanks for taking a look.
