On 10/21/26 13:12, Michal Luczaj wrote: > 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?
Thread stalled and I'm not sure how/if to proceed. As for PTR_TRUSTED in sock_map_iter_reg I'm waiting for bpf-next to open. thanks, Michal
