On Wed, Mar 04, 2026 at 11:02:23PM +0000, [email protected] 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
