Re: [PATCH bpf-next v2 26/43] bpf: Don't take an extension for an iterator program

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

On Sat, Oct 17, 2026 at 03:06 PM Tyrone Wu <tkwu@pm.me> wrote:
> Hi, I originally reported this issue a few weeks ago

Sorry, I missed that report. Both issues in there are real.

> I'm hoping for EXT to still support ITER progs for my
> usecase, so rejecting all extensions seems extreme.

It never worked though. As you found the load fails unless the func
is named bpf_iter_<target>, and then it's taken for the function of
that target. The patch only closes that hole.

> Could `bpf_iter_prog_supported()` instead have the `tinfo` search loop be
> applied on the `prog->aux->dst_prog`/`tgt_prog`, and
> `bpf_prog_ctx_arg_info_init` on the original `prog`?

That's a start, but not enough.
bpf_iter_get_func_proto() goes by attach_btf_id as well.
The iter link checks max_rdonly_access and max_rdwr_access of the iter prog
against the map. The extension has its own and nobody looks at them.

At the end it's a feature, not a fix.
Send a patch and please explain the use case.