Re: [PATCH v3 bpf-next/net 2/5] bpf: Support bpf_setsockopt() for BPF_CGROUP_INET_SOCK_CREATE.

[Stanislav Fomichev <stfomichev@gmail.com>]

On 08/26, Kuniyuki Iwashima wrote:
> On Tue, Aug 26, 2025 at 2:02 PM Stanislav Fomichev <stfomichev@gmail.com> wrote:
> >
> > On 08/26, Kuniyuki Iwashima wrote:
> > > We will store a flag in sk->sk_memcg by bpf_setsockopt() during
> > > socket() or before sk->sk_memcg is set in accept().
> > >
> > > BPF_CGROUP_INET_SOCK_CREATE is invoked by __cgroup_bpf_run_filter_sk()
> > > that passes a pointer to struct sock to the bpf prog as void *ctx.
> > >
> > > But there are no bpf_func_proto for bpf_setsockopt() that receives
> > > the ctx as a pointer to struct sock.
> > >
> > > Let's add a new bpf_setsockopt() variant for BPF_CGROUP_INET_SOCK_CREATE.
> >
> > [..]
> >
> > > Note that inet_create() is not under lock_sock().
> >
> > Does anything prevent us from grabbing the lock before running
> > SOCK_CREATE progs? This is not the fast path, so should be ok?
> > Will make it easier to reason about socket options (where all paths
> > are locked). We do similar things for sock_addr progs in
> > BPF_CGROUP_RUN_SA_PROG_LOCK.
> 
> We can do that, but the reasoning here is exactly same with
> how we allow unlocked setsockopt() for LSM hooks.  Also, SA_
> prog actually needs lock_sock() to prevent sk->{addr fields} from
> being changed concurrently.
> 
> ---8<---
> /* List of LSM hooks that trigger while the socket is _not_ locked,
>  * but it's ok to call bpf_{g,s}etsockopt because the socket is still
>  * in the early init phase.
>  */
> BTF_SET_START(bpf_lsm_unlocked_sockopt_hooks)
> #ifdef CONFIG_SECURITY_NETWORK
> BTF_ID(func, bpf_lsm_socket_post_create)
> BTF_ID(func, bpf_lsm_socket_socketpair)
> #endif
> BTF_SET_END(bpf_lsm_unlocked_sockopt_hooks)
> ---8<---

Good point, I forgot about these :-(