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

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

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.