Re: [PATCH bpf-next 2/3] bpf, sockmap: Restrict iter-context sockmap updates to iter/sockmap

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Fri, Oct 16, 2026 at 11:09 PM Michal Luczaj <mhal@rbox.co> wrote:
> [2]: commit 64c2f93fc325 ("bpf, sockmap: Take state lock for af_unix iter")

unix_state_lock() in bpf_iter_unix_seq_show() was added only for
unix_stream_bpf_update_proto() called from the iter prog.
iter/unix cannot get there anymore.
can we drop it ? can be a follow up...

> +		if (eatype == BPF_TRACE_ITER &&
> +		    env->prog->type == BPF_PROG_TYPE_TRACING &&
> +		    !strcmp(afname + strlen(BPF_ITER_FUNC_PREFIX), "sockmap"))
>  			return true;

iter/sockmap prog is not limited to ctx->sk it seems.
bpf_skc_to_unix_sock(ctx->sk)->peer is a plain PTR_TO_BTF_ID and
the value arg of bpf_map_update_elem() accepts it.
The peer doesn't have to be in any map, so it has no psock,
and sock_map_seq_show() holds nothing but rcu.
sock_map_update_elem() takes bh_lock_sock(), then sock_map_link() does
sk_psock_init() and unix_stream_bpf_update_proto() on a socket
that unix_release_sock() can be tearing down.
That's the same unlocked socket as in iter/task_file.

Should we restrict it to ctx->sk somehow?

pw-bot: cr