From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Tyrone Wu" <tkwu@pm.me>
Cc: <andrii@kernel.org>, <bpf@vger.kernel.org>,
<daniel@iogearbox.net>, <eddyz87@gmail.com>,
<josef@toxicpanda.com>, <mason@kernel.org>, <memxor@gmail.com>,
<netdev@vger.kernel.org>
Subject: Re: [PATCH bpf-next v2 26/43] bpf: Don't take an extension for an iterator program
Date: Sun, 18 Oct 2026 00:39:35 +0000 [thread overview]
Message-ID: <DM7JN7JVMJFG.18LKSE7N5TVFR@gmail.com> (raw)
In-Reply-To: <20261017220550.1661-1-tkwu@pm.me>
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.
next prev parent reply other threads:[~2026-10-18 0:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-17 22:06 [PATCH bpf-next v2 26/43] bpf: Don't take an extension for an iterator program Tyrone Wu
2026-10-18 0:39 ` Alexei Starovoitov [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-10-17 16:37 [PATCH bpf-next v2 00/43] bpf: Memory safety, lifetime and locking fixes Alexei Starovoitov
2026-10-17 16:37 ` [PATCH bpf-next v2 26/43] bpf: Don't take an extension for an iterator program Alexei Starovoitov
2026-10-17 17:17 ` bot+bpf-ci
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DM7JN7JVMJFG.18LKSE7N5TVFR@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=josef@toxicpanda.com \
--cc=mason@kernel.org \
--cc=memxor@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=tkwu@pm.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.