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

[Jiri Olsa <olsajiri@gmail.com>]

On Wed, May 27, 2026 at 02:34:37PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] check_dup_ids() uses kmemdup() to duplicate an array that can be up to 4MB in size, risking allocation failures and kernel log spam, and then sorts it without yielding, which can trigger soft lockups.
> - [Low] The patch relies on undefined symbols and incomplete struct types (`is_tracing_multi`, `struct bpf_tracing_multi_link`, `bpf_trampoline_multi_attach`, `bpf_trampoline_multi_detach`), which will cause compilation failures.
> --
> 
> Note: The format of this review has been altered to provide a free-form summary of the findings due to recitation restrictions. The original patch code is not quoted.
> 
> commit 5f2896efaf9a14c18ba8b610461b77f1dfabba8d
> Author: Jiri Olsa <jolsa@kernel.org>
> bpf: Add support for tracing multi link
> 
> This commit adds a new link type, bpf_tracing_multi_link, to allow
> attaching a BPF program to multiple function BTF IDs. It introduces
> new fields in bpf_attr::link_create for passing the BTF IDs array
> and its count.
> 
> [Severity: High]
> In the newly added check_dup_ids() function, the code uses kmemdup()
> with GFP_KERNEL to duplicate the IDs array. Since cnt can be up to
> MAX_TRACING_MULTI_CNT (which is 1,048,576), this can result in an
> order-10 contiguous kmalloc allocation of up to 4MB. Could this cause
> spurious -ENOMEM errors and spam the kernel log with allocation
> warnings on fragmented systems? It appears the caller correctly used
> kvmalloc_objs() for the original array.

will use kvmalloc_objs

> 
> Additionally, check_dup_ids() calls sort() on this potentially large
> array. Sorting over 1 million elements without yielding (such as using
> cond_resched()) might hog the CPU. Can this trigger RCU stalls or soft
> lockup watchdogs?

in reality I think the amount should be up to 100k,
not sure where to put the cond_resched anyway

> 
> [Severity: Low]
> There appear to be undefined symbols and incomplete struct types used
> in this patch, such as is_tracing_multi(), struct bpf_tracing_multi_link,
> bpf_trampoline_multi_attach(), and bpf_trampoline_multi_detach(). For
> example, the nodes_cnt field is accessed on what seems to be an
> incomplete type. While the commit message mentions that some functions
> were previously added, are they missing from this specific patch, which
> might cause compilation failures?

it's all introduced earlier, this change compiles in my setup

jirka