[RFC PATCH bpf-next v3 0/3] Upgrading uprobe and kprobe to their `multi` counterparts.
From: Varun R Mallya
Date: Fri Apr 03 2026 - 08:51:17 EST
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@xxxxxxxxx/
[2] https://lore.kernel.org/bpf/20260330110019.549079-1-varunrmallya@xxxxxxxxx/T/#m349cbbcf700d1edf0419997d14bc76dd30eec50e
[3] https://lore.kernel.org/bpf/ac0hLyMuPHiZfnVc@computer/
[4] https://lore.kernel.org/bpf/20260330110019.549079-1-varunrmallya@xxxxxxxxx
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