Re: [PATCH bpf-next 2/6] bpf: Add support to specify uprobe_multi target via file descriptor

[Jiri Olsa <olsajiri@gmail.com>]

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