On 10/19/26 21:40, Alexei Starovoitov wrote:
> On Mon, Oct 19, 2026 at 08:20 AM Michal Luczaj <[email protected]> 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?
Isn't it (currently) necessary for iter/{unix,sockmap} dgram peer
disappearing on connect(AF_UNSPEC)?
But, if I understand correctly, the removal of plain PTR_TO_BTF_ID will
make pointers like `peer` inaccessible to helpers. And we just accept progs
have to deal with potentially stale data, e.g. the value of sk_shutdown.
>>> 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-zs4ox0h...@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 ?
Ah, sure. So the same bit for unix_reg_info left for later?
I've noticed commit 7cc639dc45c5 ("bpf: Don't take an extension for an
iterator program") got merged. Should I post v2 with the env->prog->type
check dropped or you guys don't want to restrict iters anymore?
