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

[Yonghong Song <yonghong.song@linux.dev>]

On 2/18/26 11:07 AM, Andrii Nakryiko wrote:
> On Fri, Feb 13, 2026 at 9:25 PM Yonghong Song <yonghong.song@linux.dev> 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.