> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index d853f97bd154..9e3cb547651e 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -42,6 +42,7 @@
>
> #define MAX_UPROBE_MULTI_CNT (1U << 20)
> #define MAX_KPROBE_MULTI_CNT (1U << 20)
> +#define MAX_TRACING_MULTI_CNT (1U << 20)
[ ... ]
> @@ -3641,3 +3642,132 @@ __bpf_kfunc int
> bpf_copy_from_user_task_str_dynptr(const struct bpf_dynptr *dptr
[ ... ]
> +static int check_dup_ids(u32 *ids, u32 cnt)
> +{
> + int err = 0;
> +
> + /*
> + * Sort ids array (together with cookies array if defined)
> + * and check it for duplicates. The ids and cookies arrays
> + * are left sorted.
> + */
> + sort_r_nonatomic(ids, cnt, sizeof(ids[0]), ids_cmp_r, ids_swap_r, NULL);
The sort here can run over up to MAX_TRACING_MULTI_CNT (1 << 20) elements
without ever yielding the CPU. Can this hold the CPU long enough to trip
RCU stalls or the soft lockup watchdog when cnt is large?
This was raised on an earlier posting of the series, with the suggestion
to add a cond_resched() somewhere in the path. The reply noted that in
practice the count is expected to be closer to 100k rather than the full
1M limit, and that it was unclear where the cond_resched() should go, so
the code was left as is. Since MAX_TRACING_MULTI_CNT is still 1 << 20,
would it be worth revisiting whether a reschedule point is needed here?
> +
> + for (int i = 1; i < cnt; i++) {
> + if (ids[i] == ids[i - 1]) {
> + err = -EINVAL;
> + break;
> + }
> + }
> + return err;
> +}
---
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/26881310426
