Re: [PATCHv2 bpf-next 14/23] libbpf: Add bpf_link_create support for tracing_multi link

[Jiri Olsa <olsajiri@gmail.com>]

On Wed, Mar 04, 2026 at 11:02:23PM +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> > --- a/tools/lib/bpf/bpf.c
> > +++ b/tools/lib/bpf/bpf.c
> 
> [ ... ]
> 
> > +	case BPF_TRACE_FENTRY_MULTI:
> > +	case BPF_TRACE_FEXIT_MULTI:
> > +	case BPF_TRACE_FSESSION_MULTI:
> > +		attr.link_create.tracing_multi.ids = (__u64) OPTS_GET(opts, tracing_multi.ids, 0);
> > +		attr.link_create.tracing_multi.cookies = (__u64) OPTS_GET(opts, tracing_multi.cookies, 0);
> 
> Should these use ptr_to_u64() instead of a raw (__u64) cast?
> The ids and cookies fields are pointers (__u32 * and __u64 *
> respectively), and every other pointer-to-u64 conversion in
> bpf_link_create() goes through ptr_to_u64():
> 
>     attr.link_create.kprobe_multi.syms = ptr_to_u64(OPTS_GET(...));
>     attr.link_create.kprobe_multi.addrs = ptr_to_u64(OPTS_GET(...));
>     attr.link_create.uprobe_multi.path = ptr_to_u64(OPTS_GET(...));
> 
> The ptr_to_u64() helper casts through (unsigned long) first,
> which avoids implementation-defined behavior and compiler
> warnings on 32-bit builds.

yep, should be ptr_to_u64, will fix, thnx

jirka

> 
> > +		attr.link_create.tracing_multi.cnt = OPTS_GET(opts, tracing_multi.cnt, 0);
> > +		if (!OPTS_ZEROED(opts, tracing_multi))
> > +			return libbpf_err(-EINVAL);
> > +		break;
> 
> 
> ---
> 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/22692622038