Re: [PATCH bpf-next v2 01/13] bpf: Add dynptr type for skb metadata

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux