On Tue, Aug 15, 2023 at 10:47:11AM -0700, thinker.li@xxxxxxxxx wrote: > > +BTF_SET8_START(cgroup_common_btf_ids) > +BTF_ID_FLAGS(func, bpf_sockopt_dynptr_copy_to, KF_SLEEPABLE) > +BTF_ID_FLAGS(func, bpf_sockopt_dynptr_alloc, KF_SLEEPABLE) > +BTF_ID_FLAGS(func, bpf_sockopt_dynptr_install, KF_SLEEPABLE) > +BTF_ID_FLAGS(func, bpf_sockopt_dynptr_release, KF_SLEEPABLE) > +BTF_ID_FLAGS(func, bpf_sockopt_dynptr_from, KF_SLEEPABLE) > +BTF_SET8_END(cgroup_common_btf_ids) These shouldn't be sockopt specific. If we want dynptr to represent a pointer to a user contiguous user memory we should use generic kfunc that do so. I suspect a single new kfunc: bpf_dynptr_from_user_mem() would do. New dynptr type can be hidden in the kernel and all existing kfuncs dynptr_slice, dynptr_data, dynptr_write could be made to work with user memory. But I think we have to step back. Why do we need this whole thing in the first place? _why_ sockopt bpf progs needs to read and write user memory? Yes there is one page limit, but what is the use case to actually read and write beyond that? iptables sockopt was mentioned, but I don't think bpf prog can do anything useful with iptables binary blobs. They are hard enough for kernel to parse.
