Thread (18 messages) 18 messages, 4 authors, 2025-08-28

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

From: Stanislav Fomichev <hidden>
Date: 2025-08-26 21:58:23
Also in: bpf

On 08/26, Kuniyuki Iwashima wrote:
On Tue, Aug 26, 2025 at 2:02 PM Stanislav Fomichev [off-list ref] wrote:
quoted
On 08/26, Kuniyuki Iwashima wrote:
quoted
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.
[..]
quoted
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 :-(
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help