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

[Yonghong Song]

On 2/18/26 11:07 AM, Andrii Nakryiko wrote:
> 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.

Okay. Thanks for explanation. uprobe.multi is a superset of uprobe.
So I guess it is okay for libbpf to upgrade from uprobe to uprobe.multi
if necessary.

> 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.