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?

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

On Thu, Feb 12, 2026 at 7:20 AM Varun R Mallya <varunrmallya@gmail.com> 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
>