Re: [PATCHv8 bpf-next 13/29] bpf: Add support for tracing multi link

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch references several types, functions, and macros that are not defined in the provided patch nor in the baseline kernel tree, breaking the build.
--

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

bpf: Add support for tracing multi link

This commit introduces support for attaching BPF programs to multiple
function BTF IDs using a new tracing multi link type. It updates the
bpf_attr::link_create structure and adds the necessary attach/detach
plumbing for architectures with ftrace direct call support.

> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 5fcfc32c7cb44..953235ff02d74 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -5869,6 +5869,8 @@ static int link_create(union bpf_attr *attr, bpfptr_t uattr)
>  			ret = bpf_iter_link_attach(attr, uattr, prog);
>  		else if (prog->expected_attach_type == BPF_LSM_CGROUP)
>  			ret = cgroup_bpf_link_attach(attr, prog);
> +		else if (is_tracing_multi(prog->expected_attach_type))

[Severity: Low]
Is the definition of is_tracing_multi missing from this patch? The code
might fail to compile due to an implicit declaration error here.

> +			ret = bpf_tracing_multi_attach(prog, attr);
>  		else
>  			ret = bpf_tracing_prog_attach(prog,

[ ... ]

> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index d853f97bd154f..9e3cb547651e5 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c

[ ... ]

> +#if defined(CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS) && \
> +    defined(CONFIG_HAVE_SINGLE_FTRACE_DIRECT_OPS)
> +
> +static void bpf_tracing_multi_link_release(struct bpf_link *link)
> +{
> +	struct bpf_tracing_multi_link *tr_link =
> +		container_of(link, struct bpf_tracing_multi_link, link);

[Severity: Low]
Could struct bpf_tracing_multi_link be undefined in this context? Using
container_of with an incomplete type typically results in a build failure.

> +
> +	WARN_ON_ONCE(bpf_trampoline_multi_detach(link->prog, tr_link));
> +}

[ ... ]

> +int bpf_tracing_multi_attach(struct bpf_prog *prog, const union bpf_attr *attr)
> +{
> +	struct bpf_tracing_multi_link *link = NULL;

[ ... ]

> +	err = check_dup_ids(ids, cnt);
> +	if (err)
> +		goto error;
> +
> +	link = kvzalloc_flex(*link, nodes, cnt);

[Severity: Low]
Does this also fail to build because struct bpf_tracing_multi_link is an
incomplete type? It looks like kvzalloc_flex might not be able to determine
the allocation size without the full struct definition.

> +	if (!link) {
> +		err = -ENOMEM;
> +		goto error;
> +	}

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