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.
This has been tested to work with an older kernel version (5.0).

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")`.
  It has been noted in [2] that this needs to be addressed. Until then,
  I hope we can keep the exclusion of versioned symbols.

A question:
- 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 ?

Changes:

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

v2->v3 changes (v2 at [4]):
Patch 1 (uprobe auto-upgrade):
- Use str_has_pfx; fix uretprobe.single handling; simplify cnt; 
  drop temp arrays

Patch 2 (FEAT_KPROBE_MULTI_LINK):
- Use E2BIG error to detect if KPROBE_MULTI is available or not.

Patch 3 (kprobe auto-upgrade):
- Create upgrade_program function; use str_has_pfx;
  add warning instead of silent fail on
  bpf_program__attach_kprobe_opts(); drop BPF_F_SLEEPABLE check in
  favour of [3].

[1] https://lore.kernel.org/bpf/20260212152013.17351-1-varunrmallya@gmail.com/
[2] https://lore.kernel.org/bpf/20260330110019.549079-1-varunrmallya@gmail.com/T/#m349cbbcf700d1edf0419997d14bc76dd30eec50e
[3] https://lore.kernel.org/bpf/ac0hLyMuPHiZfnVc@computer/
[4] https://lore.kernel.org/bpf/20260330110019.549079-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                      |  38 ++++++
 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, 154 insertions(+), 14 deletions(-)

-- 
2.53.0