This RFC patch explores auto-upgrading standard uprobes/kprobes to use the 
multi-uprobe/multi-kprobe infrastructure when applicable.

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 in `bpf_object_prepare_progs()`
(According to the feedback received in [1].)
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.

A similar thing is done with kprobes, but I had to add a new
FEAT_KPROBE_MULTI_LINK to the kern_feature_id struct along with it's
implementation similar to it's uprobe counterpart.

Just one selftest had to be changed for uprobe but quite a few had to be
changed for kprobe. The decision to change them have been explained in
the commit descriptions.

Some Observations:
- Earlier, I noted that uprobe and uprobe_multi are equivalent. I have
  found out that uprobe_multi does not support versioned symbols such as
  those in `tools/testing/selftests/bpf/progs/test_uprobe.c` like
  `SEC("uprobe/./liburandom_read.so:  \
   urandlib_api_sameoffset@LIBURANDOM_READ_1.0.0")`.
  I believe this is something I need to fix as well to be able to support
  versioned symbols. Right now, these have been excluded from
  upgradation.

My questions:
- I want know if the conditions I have placed for FEAT_KPROBE_MULTI_LINK
  to be true in `probe_kprobe_multi_link()` are correct. I feel like it's
  incomplete and would need some more things to say definitively that
  Kprobe-multi works on a particular kernel (especially with respect 
  to the error value like that in it's uprobe counterpart.). 
  I would really appreciate suggestions here.

- I had to exclude sleepable kprobes from being upgraded due to tests
  failing. I want to know if that was a good desicion.

- I had to change the `get_func_ip_test` selftest to `?kprobe.single` from
  `?kprobe` due to offsets that were added later (after prepare_progs
  ran). This means that anyone using `?kprobe` along with offsets will
  have to change things which is not ideal. Is it alright if I exclude
  this class of SEC_DEFs from getting upgraded ?

P.S : Sorry for the incredibly late v2 on the reviews for that patch, I
was unsure of the changes I had made and wanted to thoroughly verify
things before sending them out.

v1->v2 changes: All suggestions from Andrii's review on v1 were made as
well as support for kprobe upgrade was added.

[1]: https://lore.kernel.org/bpf/20260212152013.17351-1-varunrmallya@gmail.com/

Varun R Mallya (3):
  libbpf: Auto-upgrade uprobes to multi-uprobes when supported
  libbpf: Add FEAT_KPROBE_MULTI_LINK feature probe.
  libbpf: Auto-upgrade kprobes to multi-kprobes when supported

 tools/lib/bpf/features.c                      |  37 ++++++
 tools/lib/bpf/libbpf.c                        | 114 ++++++++++++++++--
 tools/lib/bpf/libbpf_internal.h               |   2 +
 .../selftests/bpf/progs/get_func_ip_test.c    |   2 +-
 .../selftests/bpf/progs/missed_kprobe.c       |   4 +-
 .../bpf/progs/test_attach_probe_manual.c      |   4 +-
 .../selftests/bpf/progs/test_fill_link_info.c |   4 +-
 7 files changed, 151 insertions(+), 16 deletions(-)

-- 
2.52.0