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

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

On Mon, Oct 19, 2026 at 08:20 AM Michal Luczaj <mhal@rbox.co> wrote:
> On 10/17/26 01:52, Alexei Starovoitov wrote:
>> 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...
>
> So we don't care about having a stable socket state while iterating? Which
> is the case for iter/sockmap, but is unlike iter/{tcp,udp}.

Not sure. Is there a value?

> I'm not sure I see the (stream sock) issue above. psock->sk_pair holds the
> peer, so peer pointer remains valid during proto update. iter/sockmap is
> safe, because sk is held by RCU. And for iter/unix we currently take
> unix_state_lock().

got it. you're right.

>> Should we restrict it to ctx->sk somehow?
>
> I recall a discussion about having BPF helpers accept only trusted
> pointers:
> https://lore.kernel.org/bpf/CAADnVQK_93g_KkNFYXSr8ZvA1fYh4hoFRJCJFPS-zs4ox0HhAA@mail.gmail.com/
> Restricting only iter/unix seems better?

we just discussed at bpf sync meeting that it's time to
finally remove plain PTR_TO_BTF_ID.
Otherwise we keep hitting this bug everywhere.

in the meantime can we do it for this one arg ?
Mark ctx->sk as PTR_TRUSTED in sock_map_iter_reg
like iter/tcp and iter/udp do ?