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

[Michal Luczaj <mhal@rbox.co>]

On 11/1/26 02:28, Alexei Starovoitov wrote:
>> Ah, sure. So the same bit for unix_reg_info left for later?
> Yes. iter/unix cannot update sockmap after this patch.

I've meant setting PTR_TRUSTED on bpf_iter__unix::unix_sk for the sake of
unix_sk-consuming functions other than map update. bpf_setsockopt() came to
my mind, but now I've realized it doesn't really need that. So this
PTR_TRUSTED it's just a preparation for plain-PTR_TO_BTF_ID removal?

>> 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?
> 
> The former. We still want it.
> bpf-next doesn't close during merge window. Only people that
> can process patches get busier.

Ok, I got confused by Documentation/bpf/bpf_devel_QA.rst: "for the time
when the merge window is open, bpf-next will not be processed".

> Pls send the PTR_TRUSTED part in v2.
> 
> I'd also limit tracing_iter_filter() to iter/tcp and iter/udp.

Oh, right. Commit 4ddbcb886268 ("bpf: Add bpf_sock_destroy kfunc") says
bpf_sock_destroy() expects a locked sk. So if I get it right, with
bpf_iter__sockmap::sk being PTR_TRUSTED, we allow iter/sockmap to invoke
bpf_sock_destroy() on an unlocked sk?

As for now, v2 posted:
https://lore.kernel.org/bpf/20261102-sockmap-update-limit-iter-v2-0-e96a63c43b39@rbox.co/