From: Jiri Olsa <olsajiri@gmail.com>
To: bot+bpf-ci@kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
bpf@vger.kernel.org, martin.lau@linux.dev, eddyz87@gmail.com,
songliubraving@fb.com, yhs@fb.com, oleg@redhat.com,
mhiramat@kernel.org, martin.lau@kernel.org,
yonghong.song@linux.dev, clm@meta.com, ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next 2/6] bpf: Add support to specify uprobe_multi target via file descriptor
Date: Tue, 9 Jun 2026 15:24:27 +0200 [thread overview]
Message-ID: <aigUC-Jh80ilRk25@krava> (raw)
In-Reply-To: <e651c603d7b7501bbf77c4b516098c3135a8b45d445ed8e3994f6dd76d01f6a8@mail.kernel.org>
On Tue, Jun 09, 2026 at 11:17:11AM +0000, bot+bpf-ci@kernel.org wrote:
> > Allow uprobe_multi link to identify the target binary by an already
> > opened file descriptor.
> >
> > Adding new BPF_F_UPROBE_MULTI_PATH_FD flag and the path_fd field for
> > the attr.link_create.uprobe_multi struct.
> >
> > When the flag is set, we resolve the target from path_fd, without the
> > flag, we keep the existing string path behavior.
> >
> > I don't see a use case for supporting O_PATH file descriptors, because
> > we need need to read the binary first to get probes offsets, so I'm
> > using the CLASS(fd, f), which fails for O_PATH fds.
> >
> > Assisted-by: Codex:GPT-5.4
> > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
>
> This change also fixes a latent bug in bpf_link_show_fdinfo(), changing
> the exact-equality test to a bitwise test:
>
> else if (link->type == BPF_LINK_TYPE_UPROBE_MULTI)
> seq_printf(m, "link_type:\t%s\n", link->flags & BPF_F_UPROBE_MULTI_RETURN ?
> "uretprobe_multi" : "uprobe_multi");
>
> The original "link->flags == BPF_F_UPROBE_MULTI_RETURN" was harmless
> while BPF_F_UPROBE_MULTI_RETURN was the only defined uprobe_multi flag.
> This commit adds a second flag (BPF_F_UPROBE_MULTI_PATH_FD), so the
> exact "==" comparison would misreport a uretprobe_multi link as
> "uprobe_multi" whenever both flags are set.
>
> Should this carry a Fixes: tag pointing at the commit that introduced
> the fragile comparison?
>
> Fixes: 803f0700a3bb ("bpf: Show precise link_type for {uprobe,kprobe}_multi fdinfo")
hum, I don't think so, it wasn't really a bug until this change
jirka
>
>
> ---
> 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/27201419867
next prev parent reply other threads:[~2026-06-09 13:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-09 10:42 [PATCH bpf-next 0/6] bpf: Allow uprobe_multi binary specified by file descriptor Jiri Olsa
2026-06-09 10:42 ` [PATCH bpf-next 1/6] bpf: Use user_path_at for path resolution in uprobe_multi Jiri Olsa
2026-06-09 10:42 ` [PATCH bpf-next 2/6] bpf: Add support to specify uprobe_multi target via file descriptor Jiri Olsa
2026-06-09 10:57 ` sashiko-bot
2026-06-09 13:23 ` Jiri Olsa
2026-06-09 11:17 ` bot+bpf-ci
2026-06-09 13:24 ` Jiri Olsa [this message]
2026-06-09 18:22 ` Alexei Starovoitov
2026-06-10 8:31 ` Jiri Olsa
2026-06-10 14:19 ` Jiri Olsa
2026-06-09 10:42 ` [PATCH bpf-next 3/6] libbpf: Add path_fd to struct bpf_link_create_opts Jiri Olsa
2026-06-09 10:42 ` [PATCH bpf-next 4/6] selftests/bpf: Add uprobe_multi path_fd test Jiri Olsa
2026-06-09 10:42 ` [PATCH bpf-next 5/6] selftests/bpf: Add uprobe_multi path_fd fail tests Jiri Olsa
2026-06-09 10:42 ` [PATCH bpf-next 6/6] selftests/bpf: Fix typo in verify_umulti_link_info Jiri Olsa
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=aigUC-Jh80ilRk25@krava \
--to=olsajiri@gmail.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=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=mhiramat@kernel.org \
--cc=oleg@redhat.com \
--cc=songliubraving@fb.com \
--cc=yhs@fb.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox