Re: [PATCHv3 bpf-next 4/7] libbpf: Add path_fd to struct bpf_link_create_opts

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Medium] The kernel-side implementation for processing `path_fd` is completely missing.
- [Medium] The high-level libbpf API for uprobe_multi was not updated to support `path_fd`.
- [Low] The patch references a non-existent `path_fd` field in `union bpf_attr`'s `uprobe_multi` struct, which will cause a fatal compilation failure.
- [Low] The `path_fd` field is incorrectly typed as `__u32` instead of a signed integer, breaking proper semantics for special directory file descriptors like `AT_FDCWD`.
--

commit f8c10c02ad07ee86163cb02487766ca5ac58a262
Author: Jiri Olsa <jolsa@kernel.org>

libbpf: Add path_fd to struct bpf_link_create_opts

This patch adds the path_fd field to struct bpf_link_create_opts and
attempts to pass it through the kernel attribute interface for uprobe_multi
links.

> libbpf: Add path_fd to struct bpf_link_create_opts
> 
> Adding the path_fd field to struct bpf_link_create_opts and passing it
> through kernel attr interface.

[Severity: Medium]
Are there missing kernel-side changes in this patch? The commit message
states the field is being passed through the kernel attr interface, but there
are no corresponding changes in sys_bpf() or bpf_uprobe_multi_link_attach()
to extract and utilize the path_fd parameter.

[Severity: Medium]
Will this feature be exposed to the high-level libbpf API? The path_fd field
was added to the low-level struct bpf_link_create_opts, but the user-facing
struct bpf_uprobe_multi_opts and bpf_program__attach_uprobe_multi() do not
appear to be updated to support it.

> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> index f37e3416f61a5..96819c082c772 100644
> --- a/tools/lib/bpf/bpf.c
> +++ b/tools/lib/bpf/bpf.c
> @@ -842,6 +842,7 @@ int bpf_link_create(int prog_fd, int target_fd,
>  		attr.link_create.uprobe_multi.ref_ctr_offsets = ptr_to_u64(OPTS_GET(opts, uprobe_multi.ref_ctr_offsets, 0));
>  		attr.link_create.uprobe_multi.cookies = ptr_to_u64(OPTS_GET(opts, uprobe_multi.cookies, 0));
>  		attr.link_create.uprobe_multi.pid = OPTS_GET(opts, uprobe_multi.pid, 0);
> +		attr.link_create.uprobe_multi.path_fd = OPTS_GET(opts, uprobe_multi.path_fd, 0);

[Severity: Low]
Does this assignment cause a build failure? It looks like the path_fd field
has not been added to the UAPI union bpf_attr for uprobe_multi.

>  		if (!OPTS_ZEROED(opts, uprobe_multi))
>  			return libbpf_err(-EINVAL);
>  		break;

[ ... ]

> diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
> index 012354131cf66..7534a593edae2 100644
> --- a/tools/lib/bpf/bpf.h
> +++ b/tools/lib/bpf/bpf.h
> @@ -444,6 +444,7 @@ struct bpf_link_create_opts {
>  			const unsigned long *ref_ctr_offsets;
>  			const __u64 *cookies;
>  			__u32 pid;
> +			__u32 path_fd;

[Severity: Low]
Should path_fd be defined as a signed integer, such as __s32 or int? File
descriptors intended for path lookup need to support special values like
AT_FDCWD (-100), which will wrap around if stored in an unsigned 32-bit
variable.

>  		} uprobe_multi;
>  		struct {
>  			__u64 cookie;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611114230.950379-5-jolsa@kernel.org?part=1