> diff --git a/include/linux/bpf_types.h b/include/linux/bpf_types.h
> --- a/include/linux/bpf_types.h
> +++ b/include/linux/bpf_types.h
[ ... ]
> +BPF_LINK_TYPE(BPF_LINK_TYPE_TRACING_MULTI, tracing)
The existing BPF_LINK_TYPE_TRACING also uses "tracing" as its name
argument:
BPF_LINK_TYPE(BPF_LINK_TYPE_TRACING, tracing)
This means bpf_link_type_strs[] will contain "tracing" for both
BPF_LINK_TYPE_TRACING and BPF_LINK_TYPE_TRACING_MULTI, making them
indistinguishable in fdinfo output via bpf_link_show_fdinfo().
The libbpf side correctly uses "tracing_multi":
[BPF_LINK_TYPE_TRACING_MULTI] = "tracing_multi",
Should this be BPF_LINK_TYPE(BPF_LINK_TYPE_TRACING_MULTI, tracing_multi)
to match?
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
[ ... ]
> +int bpf_tracing_multi_attach(struct bpf_prog *prog, const union bpf_attr
> *attr)
> +{
[ ... ]
> + ids = kvmalloc_array(cnt, sizeof(*ids), GFP_KERNEL);
[ ... ]
> + link = kzalloc(struct_size(link, nodes, cnt), GFP_KERNEL);
^^^^^^
The ids array above uses kvmalloc_array() to handle large allocations,
but the link struct uses kzalloc(). With MAX_TRACING_MULTI_CNT at 1M
and each bpf_tracing_multi_node being roughly 40 bytes,
struct_size() can request up to ~40MB of contiguous memory. kzalloc()
is limited to KMALLOC_MAX_SIZE (~4MB on x86_64), so this will fail
for cnt values above roughly 100K.
Would kvzalloc() work here instead? bpf_tracing_multi_link_dealloc()
would need to use kvfree() accordingly:
> +static void bpf_tracing_multi_link_dealloc(struct bpf_link *link)
> +{
> + struct bpf_tracing_multi_link *tr_link =
> + container_of(link, struct bpf_tracing_multi_link, link);
> +
> + kfree(tr_link);
^^^^^
---
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/22220470181
AI-authorship-score: low
AI-authorship-explanation: Code follows established BPF subsystem patterns and
Jiri Olsa's terse kernel commit style, with no AI-characteristic verbosity or
over-documentation.
issues-found: 2
issue-severity-score: low
issue-severity-explanation: BPF_LINK_TYPE naming collision makes fdinfo output
ambiguous between tracing and tracing_multi link types, and kzalloc limits the
flex-array link allocation well below the advertised MAX_TRACING_MULTI_CNT;
neither causes crashes or data corruption.
