Re: [RFC PATCH bpf-next 0/1] Upgrading uprobe and kprobe to their `multi` counterparts.

[Andrii Nakryiko]

On Thu, Feb 12, 2026 at 7:20 AM Varun R Mallya <varunrmallya@xxxxxxxxx> wrote:
>
> This RFC patch explores auto-upgrading standard uprobes to use the
> multi-uprobe infrastructure when supported by the underlying kernel.
>
> Background:
> The BPF token concept allows privileged operations inside non-privileged
> user namespaces. However, attaching standard uprobes and kprobes
> currently relies on the perf_event_open() syscall, which is not BPF
> token-aware. Multi-uprobes and multi-kprobes bypass
> perf_event_open() entirely, attaching via the bpf() syscall instead,
> making them compatible with BPF tokens.
>
> To bridge this gap, the goal is to switch SEC("uprobe") and
> SEC("kprobe") to use multi-uprobe/kprobe under the hood. To maintain
> backward compatibility for cases where singular uprobes are explicitly
> desired, this patch also introduces SEC("uprobe.single") and
> SEC("kprobe.single").
>
> Current Implementation:
> The decision to upgrade is made at BPF program load time in
> `bpf_object_init_progs()`. If the kernel supports FEAT_UPROBE_MULTI_LINK,
> we intercept programs with section names matching "u[ret]probe" and change
> their `expected_attach_type` to BPF_TRACE_UPROBE_MULTI.
>
> During attachment, `attach_uprobe` checks this expected type and
> routes the attachment to `bpf_program__attach_uprobe_multi` accordingly.
>
> I am currently hitting an issue with selftests, and I would appreciate
> some guidance before proceeding to implement this for kprobes and fix it
> for uprobes.
>
> Selftests that rely on auto-attachment pass. However, tests that bypass
> auto-attach and manually call `bpf_program__attach_uprobe_opts()` are
> failing. Because the program's `expected_attach_type` is modified to
> multi-uprobe at load time inside `bpf_object_init_progs()`, directly
> calling the legacy attach options subsequently dies due to the type
> mismatch.
>
> How should we handle legacy manual attachments for auto-upgraded programs?
> Should `bpf_program__attach_uprobe_opts()` be taught to internally
> redirect to the multi-uprobe path if the expected type was upgraded?

I think so. bpf_uprobe_multi_opts() should have all the functionality
necessary, no?


>
> Thanks,
> Varun
>
> Varun R Mallya (1):
>   libbpf: Auto-upgrade uprobes to multi-uprobes when supported
>
>  tools/lib/bpf/libbpf.c | 42 ++++++++++++++++++++++++++++++++++++------
>  1 file changed, 36 insertions(+), 6 deletions(-)
>
> --
> 2.52.0
>