Re: [RFC PATCH bpf-next 1/1] libbpf: Auto-upgrade uprobes to multi-uprobes when supported

[Andrii Nakryiko]

On Fri, Feb 13, 2026 at 9:25 PM Yonghong Song <yonghong.song@xxxxxxxxx> wrote:
>
>
>
> On 2/13/26 9:22 AM, Varun R Mallya wrote:
> > On Thu, Feb 12, 2026 at 04:06:22PM -0800, Yonghong Song wrote:
> >>
> >> On 2/12/26 7:20 AM, Varun R Mallya wrote:
> >>> This patch modifies libbpf to automatically "upgrade" standard
> >>> SEC("uprobe") and SEC("uretprobe") programs to use the multi-uprobe
> >>> infrastructure (BPF_TRACE_UPROBE_MULTI) at load time if the kernel
> >>> supports it, making them compatible with BPF tokens.
> >>>
> >>> To maintain backward compatibility and handle rare cases where singular
> >>> uprobes are required, new SEC("uprobe.single") and SEC("uretprobe.single")
> >>> section types are introduced. These force libbpf to use the legacy
> >>> perf_event_open() attachment path.
> >> Maybe you can have bpf programs for both uprobe/uretprobe
> >> and uprobe.multi/uretprobe.multi?
> >>
> >> You can add "?" before the section name (e.g., SEC("?uprobe") so you can
> >> selectively enable those programs before loading. This one if one choice
> >> e.g. uprobe/uretprobe is not working, you can then try
> >> uprobe.multi/uretprobe.multi.
> > This is a good idea, but isn't making the upgradation built-in a better
> > choice ?
> > This way, anyone writing the program does not have to rewrite
> > the same thing twice, keeping their programs pretty clean. This also
> > moves the upgradation logic (which is probably going to be repeated multiple times)
> > into the library which makes it easier for anyone to have something BPF
> > Token compatible without having to write all this extra logic. Since "uprobe.multi"
> > is compatible with "uprobe", I don't think anything will break as well.
> > (The current breakages in the selftests are due to the patch being in
> > nascent stages and I'll fix it after I get some feedback on my
> > questions.)
>
> I still feel this is a hack, esp. for libbpf. The libbpf provides various
> APIs as the building block. Automatic upgrading inside libbpf does not
> sound right. These upgrading thing should happen in applications.
>
>  From bpf program side, you can have progs for both uprobe and uprobe_multi.
> You can have static function which can be used for both uprobe and uprobe_multi.
> It should not be hard. Looks at bpf selftest, there are quite some programs
> with prefix "?" which gives application a choice whether it should be
> enabled or not during to kernel probing or other things.
>

Yeah, you can definitely handle this without needing to duplicate the
logic in BPF code, but the idea here is to make uprobe work
transparently inside user namespaced containers (assuming BPF token
was provided), without having to explicitly accommodate this as a
special mode.

So while it can be seen as a bit of a hack, in practice whether you
use uprobe or uprobe.multi doesn't really matter (they have equivalent
features from BPF/kernel POV), but being able to just use
SEC("uprobe") is great because you don't have to worry about old
kernels not supporting uprobe.multi, plus you get automatic BPF token
compatibility.

This is a bit harder for kprobes because singular kprobe can be
installed at an offset, while kprobe.multi only support offset zero.
But even with kprobe, I think it's worth trying to transparently make
them BPF token-aware using a similar approach.