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.
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.
