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

2026-03-16 Thread Jiri Olsa
On Mon, Mar 16, 2026 at 08:35:10AM +, [email protected] wrote:
> > diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
> > --- a/tools/lib/bpf/bpf.h
> > +++ b/tools/lib/bpf/bpf.h
> > @@ -454,6 +454,11 @@ struct bpf_link_create_opts {
> > __u64 expected_revision;
> > } cgroup;
> > +   struct {
> > +   __u32 *ids;
> > +   __u64 *cookies;
> > +   __u32 cnt;
> > +   } tracing_multi;
> > };
> 
> Should the ids and cookies pointers be const-qualified here?
> Every other multi-attach member in this union uses const for
> its pointer fields, for example in kprobe_multi:
> 
> const char **syms;
> const unsigned long *addrs;
> const __u64 *cookies;
> 
> and in uprobe_multi:
> 
> const unsigned long *offsets;
> const unsigned long *ref_ctr_offsets;
> const __u64 *cookies;
> 
> These arrays are input-only (passed straight through to the
> kernel via ptr_to_u64), so marking them const would be
> consistent with the existing convention and would avoid
> compiler warnings for callers passing const arrays.

yep, will make it const

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/23133791558




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

2026-03-16 Thread bot+bpf-ci
> diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
> --- a/tools/lib/bpf/bpf.h
> +++ b/tools/lib/bpf/bpf.h
> @@ -454,6 +454,11 @@ struct bpf_link_create_opts {
>   __u64 expected_revision;
>   } cgroup;
> + struct {
> + __u32 *ids;
> + __u64 *cookies;
> + __u32 cnt;
> + } tracing_multi;
>   };

Should the ids and cookies pointers be const-qualified here?
Every other multi-attach member in this union uses const for
its pointer fields, for example in kprobe_multi:

const char **syms;
const unsigned long *addrs;
const __u64 *cookies;

and in uprobe_multi:

const unsigned long *offsets;
const unsigned long *ref_ctr_offsets;
const __u64 *cookies;

These arrays are input-only (passed straight through to the
kernel via ptr_to_u64), so marking them const would be
consistent with the existing convention and would avoid
compiler warnings for callers passing const arrays.


---
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/23133791558