From: Varun R Mallya <varunrmallya@gmail.com>
To: bot+bpf-ci@kernel.org
Cc: bpf@vger.kernel.org, jolsa@kernel.org, leon.hwang@linux.dev,
andrii@kernel.org, alan.maguire@oracle.com, ast@kernel.org,
eddyz87@gmail.com, martin.lau@linux.dev, daniel@iogearbox.net,
linux-kernel@vger.kernel.org, memxor@gmail.com, song@kernel.org,
menglong8.dong@gmail.com, martin.lau@kernel.org,
yonghong.song@linux.dev, clm@meta.com, ihor.solodrai@linux.dev
Subject: Re: [RFC PATCH bpf-next v3 2/3] libbpf: Add FEAT_KPROBE_MULTI_LINK feature probe.
Date: Fri, 10 Apr 2026 13:03:43 +0530 [thread overview]
Message-ID: <adin1waaRhIJZWbi@computer> (raw)
In-Reply-To: <3b7a777be44a7aaea75f1dc3084b3adfb32357c4bedde08d0666f6f9f3d65ba4@mail.kernel.org>
On Fri, Apr 03, 2026 at 01:22:37PM +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/tools/lib/bpf/features.c b/tools/lib/bpf/features.c
> > index 4f19a0d79b0c..01ded8a1e3c4 100644
> > --- a/tools/lib/bpf/features.c
> > +++ b/tools/lib/bpf/features.c
> > @@ -424,6 +424,41 @@ static int probe_uprobe_multi_link(int token_fd)
> > return link_fd < 0 && err == -EINVAL;
> > }
> >
> > +static int probe_kprobe_multi_link(int token_fd)
> > +{
>
> [ ... ]
>
> > + /* attaching to a valid symbol should succeed */
>
> The operation is designed to fail with E2BIG (the count is intentionally
> set above MAX_KPROBE_MULTI_CNT). Should this comment say something like
> "use a stable, always-present symbol" instead? As written, it reads like
> the attach is expected to succeed, which contradicts the comment two
> lines below about making it fail.
Yeah, I should be clarifying that. This is a nit though.
> > + link_opts.kprobe_multi.syms = &sym;
> > + /* MAX_KPROBE_MULTI_CNT is defined as (1U << 20) in kernel/trace/bpf_trace.c,
> > + * so we create one more than the allowed limit to make it fail with E2BIG.
> > + */
> > + link_opts.kprobe_multi.cnt = (1U << 20) + 1;
> > + link_fd = bpf_link_create(prog_fd, -1, BPF_TRACE_KPROBE_MULTI, &link_opts);
> > + err = -errno;
> > + if (link_fd >= 0)
> > + close(link_fd);
> > + close(prog_fd);
> > + /* Fails with E2BIG on kernels where kprobe_multi is supported */
> > + return link_fd <= 0 && err == -E2BIG;
> ^^^^
>
> Should this be "link_fd < 0" rather than "link_fd <= 0"? The
> reference function probe_uprobe_multi_link() just above uses
> "link_fd < 0 && err == -EINVAL" for the same pattern. fd 0 is
> a valid file descriptor, so "<= 0" treats a successful fd 0 as
> a failure. In practice bpf_link_create() goes through
> ensure_good_fd() which dup's fds below 3, so fd 0 cannot be
> returned, but the check is still inconsistent with the
> existing code pattern.
Good catch. I'll fix this in the next version after I get more reviews on this.
> > +}
>
> [ ... ]
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23947048141
next prev parent reply other threads:[~2026-04-10 7:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-03 12:44 [RFC PATCH bpf-next v3 0/3] Upgrading uprobe and kprobe to their `multi` counterparts Varun R Mallya
2026-04-03 12:44 ` [RFC PATCH bpf-next v3 1/3] libbpf: Auto-upgrade uprobes to multi-uprobes when supported Varun R Mallya
2026-04-03 13:35 ` bot+bpf-ci
2026-04-03 12:44 ` [RFC PATCH bpf-next v3 2/3] libbpf: Add FEAT_KPROBE_MULTI_LINK feature probe Varun R Mallya
2026-04-03 13:22 ` bot+bpf-ci
2026-04-10 7:33 ` Varun R Mallya [this message]
2026-04-03 12:44 ` [RFC PATCH bpf-next v3 3/3] libbpf: Auto-upgrade kprobes to multi-kprobes when supported Varun R Mallya
2026-04-03 13:35 ` bot+bpf-ci
2026-04-10 7:36 ` Varun R Mallya
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=adin1waaRhIJZWbi@computer \
--to=varunrmallya@gmail.com \
--cc=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=ihor.solodrai@linux.dev \
--cc=jolsa@kernel.org \
--cc=leon.hwang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=menglong8.dong@gmail.com \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/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.