>> >> Add logic to call bpf_setsockopt and bpf_getsockopt from >> setsockopt BPF programs. >> Example use case, when the user sets the IPV6_TCLASS socket option >> we would also like to change the tcp-cc for that socket. >> We don't have any use case for calling bpf_setsockopt from >> supposedly read-only sys_getsockopti, so it is made available to >> BPF_CGROUP_SETSOCKOPT only. >> >> Signed-off-by: Prankur gupta <prankgup@xxxxxx> >> --- >> kernel/bpf/cgroup.c | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c >> index a1dedba4c174..9c92eff9af95 100644 >> --- a/kernel/bpf/cgroup.c >> +++ b/kernel/bpf/cgroup.c >> @@ -1873,6 +1873,14 @@ cg_sockopt_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog) >> return &bpf_sk_storage_get_proto; >> case BPF_FUNC_sk_storage_delete: >> return &bpf_sk_storage_delete_proto; >> + case BPF_FUNC_setsockopt: >> + if (prog->expected_attach_type == BPF_CGROUP_SETSOCKOPT) >> + return &bpf_sk_setsockopt_proto; >> + return NULL; >> + case BPF_FUNC_getsockopt: >> + if (prog->expected_attach_type == BPF_CGROUP_SETSOCKOPT) >> + return &bpf_sk_getsockopt_proto; > >Is there any problem enabling bpf_getsockopt() for >BPF_CGROUP_GETSOCKOPT program type? > No, there's no problem but there's no usecase (which i can think of) where a user wants to set or get some socket option for a getsockopt call >> + return NULL; >> #endif >> #ifdef CONFIG_INET >> case BPF_FUNC_tcp_sock: >> -- >> 2.30.2 >>
