[RFC PATCH bpf-next v3 0/3] Upgrading uprobe and kprobe to their `multi` counterparts.

[RFC PATCH bpf-next v3 0/3] Upgrading uprobe and kprobe to their `multi` counterparts.

[Varun R Mallya]

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

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

[Varun R Mallya]

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.

tools/testing/selftests/bpf/progs/test_fill_link_info.c has been
modified to use SEC("uprobe.single") as it asserts the program type to be
`BPF_LINK_TYPE_PERF_EVENT` and checks properties related to uprobes that
use perf.

Signed-off-by: Varun R Mallya <varunrmallya@gmail.com>
---
 tools/lib/bpf/libbpf.c                        | 42 ++++++++++++++++++-
 .../selftests/bpf/progs/test_fill_link_info.c |  2 +-
 2 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 9ea41f40dc82..6f56bdc243eb 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -8294,6 +8294,22 @@ static int bpf_object_prepare_progs(struct bpf_object *obj)
 
 	for (i = 0; i < obj->nr_programs; i++) {
 		prog = &obj->programs[i];
+
+		if (kernel_supports(obj, FEAT_UPROBE_MULTI_LINK)) {
+			const char *sec_name = prog->sec_name;
+			/* Here, we filter out for u[ret]probe or "u[ret]probe/"
+			 * but we leave out anything with an '@'
+			 * in it as uprobe_multi does not support versioned
+			 * symbols yet, so we don't upgrade.
+			 */
+			if ((strcmp(sec_name, "uprobe") == 0 ||
+			     str_has_pfx(sec_name, "uprobe/") ||
+			     strcmp(sec_name, "uretprobe") == 0 ||
+			     str_has_pfx(sec_name, "uretprobe/")) &&
+			    !strchr(sec_name, '@'))
+				prog->expected_attach_type = BPF_TRACE_UPROBE_MULTI;
+		}
+
 		err = bpf_object__sanitize_prog(obj, prog);
 		if (err)
 			return err;
@@ -9955,9 +9971,11 @@ static const struct bpf_sec_def section_defs[] = {
 	SEC_DEF("kprobe+",		KPROBE,	0, SEC_NONE, attach_kprobe),
 	SEC_DEF("uprobe+",		KPROBE,	0, SEC_NONE, attach_uprobe),
 	SEC_DEF("uprobe.s+",		KPROBE,	0, SEC_SLEEPABLE, attach_uprobe),
+	SEC_DEF("uprobe.single+",	KPROBE,	0, SEC_NONE, attach_uprobe),
 	SEC_DEF("kretprobe+",		KPROBE, 0, SEC_NONE, attach_kprobe),
 	SEC_DEF("uretprobe+",		KPROBE, 0, SEC_NONE, attach_uprobe),
 	SEC_DEF("uretprobe.s+",		KPROBE, 0, SEC_SLEEPABLE, attach_uprobe),
+	SEC_DEF("uretprobe.single+",	KPROBE,	0, SEC_NONE, attach_uprobe),
 	SEC_DEF("kprobe.multi+",	KPROBE,	BPF_TRACE_KPROBE_MULTI, SEC_NONE, attach_kprobe_multi),
 	SEC_DEF("kretprobe.multi+",	KPROBE,	BPF_TRACE_KPROBE_MULTI, SEC_NONE, attach_kprobe_multi),
 	SEC_DEF("kprobe.session+",	KPROBE,	BPF_TRACE_KPROBE_SESSION, SEC_NONE, attach_kprobe_session),
@@ -12783,6 +12801,27 @@ bpf_program__attach_uprobe_opts(const struct bpf_program *prog, pid_t pid,
 		func_offset += sym_off;
 	}
 
+	/* This provides backwards compatibility to programs using uprobe, but
+	 * have been auto-upgraded to multi uprobe.
+	 */
+	if (prog->expected_attach_type == BPF_TRACE_UPROBE_MULTI) {
+		LIBBPF_OPTS(bpf_uprobe_multi_opts, multi_opts);
+		__u64 bpf_cookie;
+
+		multi_opts.cnt = 1;
+		multi_opts.retprobe = OPTS_GET(opts, retprobe, false);
+		if (func_offset || func_name)
+			multi_opts.offsets = &func_offset;
+		if (ref_ctr_off)
+			multi_opts.ref_ctr_offsets = &ref_ctr_off;
+
+		bpf_cookie = OPTS_GET(opts, bpf_cookie, 0);
+		if (bpf_cookie)
+			multi_opts.cookies = &bpf_cookie;
+
+		return bpf_program__attach_uprobe_multi(prog, pid, binary_path,
+							NULL, &multi_opts);
+	}
 	legacy = determine_uprobe_perf_type() < 0;
 	switch (attach_mode) {
 	case PROBE_ATTACH_MODE_LEGACY:
@@ -12903,7 +12942,8 @@ static int attach_uprobe(const struct bpf_program *prog, long cookie, struct bpf
 				offset = 0;
 		}
 		opts.retprobe = strcmp(probe_type, "uretprobe") == 0 ||
-				strcmp(probe_type, "uretprobe.s") == 0;
+				strcmp(probe_type, "uretprobe.s") == 0 ||
+				strcmp(probe_type, "uretprobe.single") == 0;
 		if (opts.retprobe && offset != 0) {
 			pr_warn("prog '%s': uretprobes do not support offset specification\n",
 				prog->name);
diff --git a/tools/testing/selftests/bpf/progs/test_fill_link_info.c b/tools/testing/selftests/bpf/progs/test_fill_link_info.c
index fac33a14f200..8e47a818462f 100644
--- a/tools/testing/selftests/bpf/progs/test_fill_link_info.c
+++ b/tools/testing/selftests/bpf/progs/test_fill_link_info.c
@@ -28,7 +28,7 @@ int BPF_PROG(kprobe_run)
 	return 0;
 }
 
-SEC("uprobe")
+SEC("uprobe.single")
 int BPF_PROG(uprobe_run)
 {
 	return 0;
-- 
2.53.0

[RFC PATCH bpf-next v3 2/3] libbpf: Add FEAT_KPROBE_MULTI_LINK feature probe.

[Varun R Mallya]

Add FEAT_KPROBE_MULTI_LINK, similar to UPROBE_MULTI_LINK
by loading and creating a link for a small BPF program with
BPF_TRACE_KPROBE_MULTI as the expected attach type, and
then checking the success of the operation.

Signed-off-by: Varun R Mallya <varunrmallya@gmail.com>
---
 tools/lib/bpf/features.c        | 38 +++++++++++++++++++++++++++++++++
 tools/lib/bpf/libbpf_internal.h |  2 ++
 2 files changed, 40 insertions(+)

diff --git a/tools/lib/bpf/features.c b/tools/lib/bpf/features.c
index 4f19a0d79b0c..01ded8a1e3c4 100644
--- a/tools/lib/bpf/features.c
+++ b/tools/lib/bpf/features.c
@@ -424,6 +424,41 @@ static int probe_uprobe_multi_link(int token_fd)
 	return link_fd < 0 && err == -EINVAL;
 }
 
+static int probe_kprobe_multi_link(int token_fd)
+{
+	LIBBPF_OPTS(bpf_prog_load_opts, load_opts,
+		    .expected_attach_type = BPF_TRACE_KPROBE_MULTI,
+		    .token_fd = token_fd,
+		    .prog_flags = token_fd ? BPF_F_TOKEN_FD : 0,
+	);
+	LIBBPF_OPTS(bpf_link_create_opts, link_opts);
+	struct bpf_insn insns[] = {
+		BPF_MOV64_IMM(BPF_REG_0, 0),
+		BPF_EXIT_INSN(),
+	};
+	int prog_fd, link_fd, err;
+	const char *sym = "bpf_map_lookup_elem"; /* stable, always present */
+
+	prog_fd = bpf_prog_load(BPF_PROG_TYPE_KPROBE, NULL, "GPL",
+				insns, ARRAY_SIZE(insns), &load_opts);
+	if (prog_fd < 0)
+		return -errno;
+
+	/* attaching to a valid symbol should succeed */
+	link_opts.kprobe_multi.syms = &sym;
+	/* MAX_KPROBE_MULTI_CNT is defined as (1U << 20) in kernel/trace/bpf_trace.c,
+	 * so we create one more than the allowed limit to make it fail with E2BIG.
+	 */
+	link_opts.kprobe_multi.cnt = (1U << 20) + 1;
+	link_fd = bpf_link_create(prog_fd, -1, BPF_TRACE_KPROBE_MULTI, &link_opts);
+	err = -errno;
+	if (link_fd >= 0)
+		close(link_fd);
+	close(prog_fd);
+	/* Fails with E2BIG on kernels where kprobe_multi is supported */
+	return link_fd <= 0 && err == -E2BIG;
+}
+
 static int probe_kern_bpf_cookie(int token_fd)
 {
 	struct bpf_insn insns[] = {
@@ -699,6 +734,9 @@ static struct kern_feature_desc {
 	[FEAT_BTF_LAYOUT] = {
 		"kernel supports BTF layout", probe_kern_btf_layout,
 	},
+	[FEAT_KPROBE_MULTI_LINK] = {
+		"BPF multi-kprobe link support", probe_kprobe_multi_link,
+	},
 };
 
 bool feat_supported(struct kern_feature_cache *cache, enum kern_feature_id feat_id)
diff --git a/tools/lib/bpf/libbpf_internal.h b/tools/lib/bpf/libbpf_internal.h
index cabdaef79098..b3cb216aadae 100644
--- a/tools/lib/bpf/libbpf_internal.h
+++ b/tools/lib/bpf/libbpf_internal.h
@@ -398,6 +398,8 @@ enum kern_feature_id {
 	FEAT_UPROBE_SYSCALL,
 	/* Kernel supports BTF layout information */
 	FEAT_BTF_LAYOUT,
+	/* BPF multi-kprobe link support */
+	FEAT_KPROBE_MULTI_LINK,
 	__FEAT_CNT,
 };
 
-- 
2.53.0

[RFC PATCH bpf-next v3 3/3] libbpf: Auto-upgrade kprobes to multi-kprobes when supported

[Varun R Mallya]

This patch modifies libbpf to automatically upgrade standard
SEC("kprobe") and SEC("kretprobe") programs to use the multi-kprobe
infrastructure (BPF_TRACE_KPROBE_MULTI) at load time if the kernel
supports it, making them compatible with BPF tokens.

To maintain backward compatibility and handle cases where singular
kprobes are required, new SEC("kprobe.single") and SEC("kretprobe.single")
section types are introduced. These force libbpf to use the legacy
perf_event_open() attachment path.

The following explain the reasoning for changing selftests:
- test_fill_link_info.c kprobe→kprobe.single:
  this test calls bpf_link_get_info_by_fd and asserts
  BPF_LINK_TYPE_PERF_EVENT and it explicitly needs the perf_event
  attachment path, which breaks after auto-upgrade to multi.

- test_attach_probe_manual.c kprobe→kprobe.single,
  kretprobe→kretprobe.single:
  this test exercises all four explicit attachment modes
  (default, legacy, perf, link) and PROBE_ATTACH_MODE_LINK
  creates a perf_event BPF link which the kernel rejects
  for a prog loaded with expected_attach_type = BPF_TRACE_KPROBE_MULTI.

- missed_kprobe.c kprobe->kprobe.single:
  The link is explicitly checked in the tests due to which it fails if
  we do not specifically kprobe.single this.

- get_func_ip_test.c ?kprobe→?kprobe.single: the ? is stripped from
  sec_name by libbpf at init time so the prog still gets auto-upgraded.
  It is then manually attached with a non-zero body offset,
  which kprobe_multi doesn't support.

Signed-off-by: Varun R Mallya <varunrmallya@gmail.com>
---
 tools/lib/bpf/libbpf.c                        | 104 ++++++++++++++----
 .../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 |   2 +-
 5 files changed, 88 insertions(+), 28 deletions(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 6f56bdc243eb..7c6680759b0a 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -8286,6 +8286,43 @@ bpf_object__load_progs(struct bpf_object *obj, int log_level)
 	return 0;
 }
 
+/* This function is responsible for upgrading uprobes and kprobes
+ * to their multi counterparts.
+ */
+static int upgrade_program(struct bpf_object *obj, struct bpf_program *prog)
+{
+	const char *sec_name = prog->sec_name;
+
+	if (kernel_supports(obj, FEAT_UPROBE_MULTI_LINK)) {
+		/* Here, we filter out for u[ret]probe or "u[ret]probe/"
+		 * but we leave out anything with an '@'
+		 * in it as uprobe_multi does not support versioned
+		 * symbols yet, so we don't upgrade.
+		 */
+		if ((strcmp(sec_name, "uprobe") == 0 ||
+		     str_has_pfx(sec_name, "uprobe/") ||
+		     strcmp(sec_name, "uretprobe") == 0 ||
+		     str_has_pfx(sec_name, "uretprobe/")) &&
+		    !strchr(sec_name, '@'))
+			prog->expected_attach_type = BPF_TRACE_UPROBE_MULTI;
+	}
+
+	if (kernel_supports(obj, FEAT_KPROBE_MULTI_LINK)) {
+		/* Here, we filter out for k[ret]probe or "k[ret]probe/".
+		 * We also do not allow '+' as we do not support
+		 * offsets in kprobe_multi.
+		 */
+		if ((strcmp(sec_name, "kprobe") == 0 ||
+		     str_has_pfx(sec_name, "kprobe/") ||
+		     strcmp(sec_name, "kretprobe") == 0 ||
+		     str_has_pfx(sec_name, "kretprobe/")) &&
+		    !strchr(sec_name, '+'))
+			prog->expected_attach_type = BPF_TRACE_KPROBE_MULTI;
+	}
+
+	return 0;
+}
+
 static int bpf_object_prepare_progs(struct bpf_object *obj)
 {
 	struct bpf_program *prog;
@@ -8294,22 +8331,9 @@ static int bpf_object_prepare_progs(struct bpf_object *obj)
 
 	for (i = 0; i < obj->nr_programs; i++) {
 		prog = &obj->programs[i];
-
-		if (kernel_supports(obj, FEAT_UPROBE_MULTI_LINK)) {
-			const char *sec_name = prog->sec_name;
-			/* Here, we filter out for u[ret]probe or "u[ret]probe/"
-			 * but we leave out anything with an '@'
-			 * in it as uprobe_multi does not support versioned
-			 * symbols yet, so we don't upgrade.
-			 */
-			if ((strcmp(sec_name, "uprobe") == 0 ||
-			     str_has_pfx(sec_name, "uprobe/") ||
-			     strcmp(sec_name, "uretprobe") == 0 ||
-			     str_has_pfx(sec_name, "uretprobe/")) &&
-			    !strchr(sec_name, '@'))
-				prog->expected_attach_type = BPF_TRACE_UPROBE_MULTI;
-		}
-
+		err = upgrade_program(obj, prog);
+		if (err)
+			return err;
 		err = bpf_object__sanitize_prog(obj, prog);
 		if (err)
 			return err;
@@ -9969,10 +9993,12 @@ static const struct bpf_sec_def section_defs[] = {
 	SEC_DEF("sk_reuseport/migrate",	SK_REUSEPORT, BPF_SK_REUSEPORT_SELECT_OR_MIGRATE, SEC_ATTACHABLE),
 	SEC_DEF("sk_reuseport",		SK_REUSEPORT, BPF_SK_REUSEPORT_SELECT, SEC_ATTACHABLE),
 	SEC_DEF("kprobe+",		KPROBE,	0, SEC_NONE, attach_kprobe),
+	SEC_DEF("kprobe.single+",	KPROBE,	0, SEC_NONE, attach_kprobe),
 	SEC_DEF("uprobe+",		KPROBE,	0, SEC_NONE, attach_uprobe),
 	SEC_DEF("uprobe.s+",		KPROBE,	0, SEC_SLEEPABLE, attach_uprobe),
 	SEC_DEF("uprobe.single+",	KPROBE,	0, SEC_NONE, attach_uprobe),
 	SEC_DEF("kretprobe+",		KPROBE, 0, SEC_NONE, attach_kprobe),
+	SEC_DEF("kretprobe.single+",	KPROBE, 0, SEC_NONE, attach_kprobe),
 	SEC_DEF("uretprobe+",		KPROBE, 0, SEC_NONE, attach_uprobe),
 	SEC_DEF("uretprobe.s+",		KPROBE, 0, SEC_SLEEPABLE, attach_uprobe),
 	SEC_DEF("uretprobe.single+",	KPROBE,	0, SEC_NONE, attach_uprobe),
@@ -11814,6 +11840,30 @@ bpf_program__attach_kprobe_opts(const struct bpf_program *prog,
 	offset = OPTS_GET(opts, offset, 0);
 	pe_opts.bpf_cookie = OPTS_GET(opts, bpf_cookie, 0);
 
+	/* This provides backwards compatibility to programs using kprobe, but
+	 * have been auto-upgraded to multi kprobe.
+	 */
+	if (prog->expected_attach_type == BPF_TRACE_KPROBE_MULTI &&
+	    offset == 0 && attach_mode == PROBE_ATTACH_MODE_DEFAULT) {
+		LIBBPF_OPTS(bpf_kprobe_multi_opts, multi_opts);
+		__u64 bpf_cookie;
+
+		multi_opts.retprobe = OPTS_GET(opts, retprobe, false);
+		multi_opts.syms = &func_name;
+		multi_opts.cnt = 1;
+		bpf_cookie = OPTS_GET(opts, bpf_cookie, 0);
+		if (bpf_cookie)
+			multi_opts.cookies = &bpf_cookie;
+
+		return bpf_program__attach_kprobe_multi_opts(prog, NULL, &multi_opts);
+	}
+
+	if (prog->expected_attach_type == BPF_TRACE_KPROBE_MULTI) {
+		pr_warn("prog '%s': multi-kprobe upgrade failed (off=%lu, mode=%d); use SEC(\"kprobe.single\")\n",
+			prog->name, offset, attach_mode);
+		return libbpf_err_ptr(-ENOTSUP);
+	}
+
 	legacy = determine_kprobe_perf_type() < 0;
 	switch (attach_mode) {
 	case PROBE_ATTACH_MODE_LEGACY:
@@ -12268,14 +12318,24 @@ static int attach_kprobe(const struct bpf_program *prog, long cookie, struct bpf
 	*link = NULL;
 
 	/* no auto-attach for SEC("kprobe") and SEC("kretprobe") */
-	if (strcmp(prog->sec_name, "kprobe") == 0 || strcmp(prog->sec_name, "kretprobe") == 0)
+	if (strcmp(prog->sec_name, "kprobe") == 0 ||
+	    strcmp(prog->sec_name, "kretprobe") == 0 ||
+	    strcmp(prog->sec_name, "kprobe.single") == 0 ||
+	    strcmp(prog->sec_name, "kretprobe.single") == 0)
 		return 0;
 
-	opts.retprobe = str_has_pfx(prog->sec_name, "kretprobe/");
-	if (opts.retprobe)
-		func_name = prog->sec_name + sizeof("kretprobe/") - 1;
-	else
-		func_name = prog->sec_name + sizeof("kprobe/") - 1;
+	if (str_has_pfx(prog->sec_name, "kretprobe/") ||
+	    str_has_pfx(prog->sec_name, "kretprobe.single/")) {
+		opts.retprobe = true;
+		func_name = str_has_pfx(prog->sec_name, "kretprobe/")
+			    ? prog->sec_name + sizeof("kretprobe/") - 1
+			    : prog->sec_name + sizeof("kretprobe.single/") - 1;
+	} else {
+		opts.retprobe = false;
+		func_name = str_has_pfx(prog->sec_name, "kprobe.single/")
+			    ? prog->sec_name + sizeof("kprobe.single/") - 1
+			    : prog->sec_name + sizeof("kprobe/") - 1;
+	}
 
 	n = sscanf(func_name, "%m[a-zA-Z0-9_.]+%li", &func, &offset);
 	if (n < 1) {
diff --git a/tools/testing/selftests/bpf/progs/get_func_ip_test.c b/tools/testing/selftests/bpf/progs/get_func_ip_test.c
index 2011cacdeb18..a039760b8516 100644
--- a/tools/testing/selftests/bpf/progs/get_func_ip_test.c
+++ b/tools/testing/selftests/bpf/progs/get_func_ip_test.c
@@ -73,7 +73,7 @@ int BPF_PROG(test5, int a, int *b, int ret)
 }
 
 __u64 test6_result = 0;
-SEC("?kprobe")
+SEC("?kprobe.single")
 int test6(struct pt_regs *ctx)
 {
 	__u64 addr = bpf_get_func_ip(ctx);
diff --git a/tools/testing/selftests/bpf/progs/missed_kprobe.c b/tools/testing/selftests/bpf/progs/missed_kprobe.c
index 51a4fe64c917..5f405888ed0b 100644
--- a/tools/testing/selftests/bpf/progs/missed_kprobe.c
+++ b/tools/testing/selftests/bpf/progs/missed_kprobe.c
@@ -16,14 +16,14 @@ int BPF_PROG(trigger)
 	return 0;
 }
 
-SEC("kprobe/bpf_fentry_test1")
+SEC("kprobe.single/bpf_fentry_test1")
 int test1(struct pt_regs *ctx)
 {
 	bpf_kfunc_common_test();
 	return 0;
 }
 
-SEC("kprobe/bpf_kfunc_common_test")
+SEC("kprobe.single/bpf_kfunc_common_test")
 int test2(struct pt_regs *ctx)
 {
 	return 0;
diff --git a/tools/testing/selftests/bpf/progs/test_attach_probe_manual.c b/tools/testing/selftests/bpf/progs/test_attach_probe_manual.c
index 7f08bce94596..eb0fa3b39c5f 100644
--- a/tools/testing/selftests/bpf/progs/test_attach_probe_manual.c
+++ b/tools/testing/selftests/bpf/progs/test_attach_probe_manual.c
@@ -14,14 +14,14 @@ int uretprobe_res = 0;
 int uprobe_byname_res = 0;
 void *user_ptr = 0;
 
-SEC("kprobe")
+SEC("kprobe.single")
 int handle_kprobe(struct pt_regs *ctx)
 {
 	kprobe_res = 1;
 	return 0;
 }
 
-SEC("kretprobe")
+SEC("kretprobe.single")
 int handle_kretprobe(struct pt_regs *ctx)
 {
 	kretprobe_res = 2;
diff --git a/tools/testing/selftests/bpf/progs/test_fill_link_info.c b/tools/testing/selftests/bpf/progs/test_fill_link_info.c
index 8e47a818462f..bc6cfed71fb8 100644
--- a/tools/testing/selftests/bpf/progs/test_fill_link_info.c
+++ b/tools/testing/selftests/bpf/progs/test_fill_link_info.c
@@ -22,7 +22,7 @@ int unused(void)
 			CONFIG_PPC64 ? 0 : 1;
 }
 
-SEC("kprobe")
+SEC("kprobe.single")
 int BPF_PROG(kprobe_run)
 {
 	return 0;
-- 
2.53.0

Re: [RFC PATCH bpf-next v3 2/3] libbpf: Add FEAT_KPROBE_MULTI_LINK feature probe.

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]

> diff --git a/tools/lib/bpf/features.c b/tools/lib/bpf/features.c
> index 4f19a0d79b0c..01ded8a1e3c4 100644
> --- a/tools/lib/bpf/features.c
> +++ b/tools/lib/bpf/features.c
> @@ -424,6 +424,41 @@ static int probe_uprobe_multi_link(int token_fd)
>  	return link_fd < 0 && err == -EINVAL;
>  }
>
> +static int probe_kprobe_multi_link(int token_fd)
> +{

[ ... ]

> +	/* attaching to a valid symbol should succeed */

The operation is designed to fail with E2BIG (the count is intentionally
set above MAX_KPROBE_MULTI_CNT). Should this comment say something like
"use a stable, always-present symbol" instead? As written, it reads like
the attach is expected to succeed, which contradicts the comment two
lines below about making it fail.

> +	link_opts.kprobe_multi.syms = &sym;
> +	/* MAX_KPROBE_MULTI_CNT is defined as (1U << 20) in kernel/trace/bpf_trace.c,
> +	 * so we create one more than the allowed limit to make it fail with E2BIG.
> +	 */
> +	link_opts.kprobe_multi.cnt = (1U << 20) + 1;
> +	link_fd = bpf_link_create(prog_fd, -1, BPF_TRACE_KPROBE_MULTI, &link_opts);
> +	err = -errno;
> +	if (link_fd >= 0)
> +		close(link_fd);
> +	close(prog_fd);
> +	/* Fails with E2BIG on kernels where kprobe_multi is supported */
> +	return link_fd <= 0 && err == -E2BIG;
                    ^^^^

Should this be "link_fd < 0" rather than "link_fd <= 0"?  The
reference function probe_uprobe_multi_link() just above uses
"link_fd < 0 && err == -EINVAL" for the same pattern.  fd 0 is
a valid file descriptor, so "<= 0" treats a successful fd 0 as
a failure.  In practice bpf_link_create() goes through
ensure_good_fd() which dup's fds below 3, so fd 0 cannot be
returned, but the check is still inconsistent with the
existing code pattern.

> +}

[ ... ]


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23947048141

Re: [RFC PATCH bpf-next v3 3/3] libbpf: Auto-upgrade kprobes to multi-kprobes when supported

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]

> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index bc749b9c291e..f566527d95f3 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c

[ ... ]

> @@ -11841,6 +11867,30 @@ bpf_program__attach_kprobe_opts(const struct bpf_program *prog,
>  	offset = OPTS_GET(opts, offset, 0);
>  	pe_opts.bpf_cookie = OPTS_GET(opts, bpf_cookie, 0);
>
> +	/* This provides backwards compatibility to programs using kprobe, but
> +	 * have been auto-upgraded to multi kprobe.
> +	 */
> +	if (prog->expected_attach_type == BPF_TRACE_KPROBE_MULTI &&
> +	    offset == 0 && attach_mode == PROBE_ATTACH_MODE_DEFAULT) {

[ ... ]

> +	if (prog->expected_attach_type == BPF_TRACE_KPROBE_MULTI) {
> +		pr_warn("prog '%s': multi-kprobe upgrade failed (off=%lu, mode=%d); use SEC(\"kprobe.single\")\n",
> +			prog->name, offset, attach_mode);

Should this use %zu instead of %lu for offset?  It is declared as
size_t in this function, and the existing pr_warn() calls further
down use %zx for the same variable.

> +		return libbpf_err_ptr(-ENOTSUP);
> +	}

[ ... ]

> @@ -12297,14 +12347,24 @@ static int attach_kprobe(const struct bpf_program *prog, long cookie, struct bpf
>  	*link = NULL;
>
>  	/* no auto-attach for SEC("kprobe") and SEC("kretprobe") */
> -	if (strcmp(prog->sec_name, "kprobe") == 0 || strcmp(prog->sec_name, "kretprobe") == 0)
> +	if (strcmp(prog->sec_name, "kprobe") == 0 ||
> +	    strcmp(prog->sec_name, "kretprobe") == 0 ||
> +	    strcmp(prog->sec_name, "kprobe.single") == 0 ||
> +	    strcmp(prog->sec_name, "kretprobe.single") == 0)
>  		return 0;

The comment above still only mentions SEC("kprobe") and
SEC("kretprobe").  Could it be updated to also mention the .single
variants that are now handled here?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23947048141

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

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 2873 bytes --]

> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 42bdba4efd0c..bc749b9c291e 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c

[ ... ]

> @@ -12812,6 +12830,27 @@ bpf_program__attach_uprobe_opts(const struct bpf_program *prog, pid_t pid,
>  		func_offset += sym_off;
>  	}
>
> +	/* This provides backwards compatibility to programs using uprobe, but
> +	 * have been auto-upgraded to multi uprobe.
> +	 */
> +	if (prog->expected_attach_type == BPF_TRACE_UPROBE_MULTI) {
> +		LIBBPF_OPTS(bpf_uprobe_multi_opts, multi_opts);
> +		__u64 bpf_cookie;
> +
> +		multi_opts.cnt = 1;
> +		multi_opts.retprobe = OPTS_GET(opts, retprobe, false);
> +		if (func_offset || func_name)
> +			multi_opts.offsets = &func_offset;
> +		if (ref_ctr_off)
> +			multi_opts.ref_ctr_offsets = &ref_ctr_off;
> +
> +		bpf_cookie = OPTS_GET(opts, bpf_cookie, 0);
> +		if (bpf_cookie)
> +			multi_opts.cookies = &bpf_cookie;
> +
> +		return bpf_program__attach_uprobe_multi(prog, pid, binary_path,
> +							NULL, &multi_opts);
> +	}
>  	legacy = determine_uprobe_perf_type() < 0;
>  	switch (attach_mode) {
>  	case PROBE_ATTACH_MODE_LEGACY:

Should the redirect to bpf_program__attach_uprobe_multi() take attach_mode
into account?

The attach_mode field is extracted from opts earlier in this function:

    attach_mode = OPTS_GET(opts, attach_mode, PROBE_ATTACH_MODE_DEFAULT);

but the multi-uprobe redirect returns before the switch(attach_mode) is
ever reached. If a caller explicitly passes PROBE_ATTACH_MODE_LEGACY or
PROBE_ATTACH_MODE_PERF, that request is silently ignored and the
attachment goes through the multi-uprobe path regardless.

The kernel's __perf_event_set_bpf_prog() does not check
prog->expected_attach_type for KPROBE programs, so perf-event-based
attachment would still work for auto-upgraded programs if the code were
to fall through.

For example, test_attach_probe_manual() in
prog_tests/attach_probe.c calls bpf_program__attach_uprobe_opts()
with PROBE_ATTACH_MODE_LEGACY and PROBE_ATTACH_MODE_PERF on programs
using SEC("uprobe") and SEC("uretprobe") from
progs/test_attach_probe_manual.c. After auto-upgrade, these tests
would silently use multi-uprobe attachment instead of exercising the
requested attachment modes.

Would it make sense to skip the multi-uprobe redirect when attach_mode
is explicitly set to a non-default value, something like:

    if (prog->expected_attach_type == BPF_TRACE_UPROBE_MULTI &&
        attach_mode == PROBE_ATTACH_MODE_DEFAULT) {

This would preserve the transparent upgrade for the common case while
still respecting explicit attachment mode requests.


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23947048141

Re: [RFC PATCH bpf-next v3 2/3] libbpf: Add FEAT_KPROBE_MULTI_LINK feature probe.

[Varun R Mallya]

On Fri, Apr 03, 2026 at 01:22:37PM +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/tools/lib/bpf/features.c b/tools/lib/bpf/features.c
> > index 4f19a0d79b0c..01ded8a1e3c4 100644
> > --- a/tools/lib/bpf/features.c
> > +++ b/tools/lib/bpf/features.c
> > @@ -424,6 +424,41 @@ static int probe_uprobe_multi_link(int token_fd)
> >  	return link_fd < 0 && err == -EINVAL;
> >  }
> >
> > +static int probe_kprobe_multi_link(int token_fd)
> > +{
> 
> [ ... ]
> 
> > +	/* attaching to a valid symbol should succeed */
> 
> The operation is designed to fail with E2BIG (the count is intentionally
> set above MAX_KPROBE_MULTI_CNT). Should this comment say something like
> "use a stable, always-present symbol" instead? As written, it reads like
> the attach is expected to succeed, which contradicts the comment two
> lines below about making it fail.

Yeah, I should be clarifying that. This is a nit though.

> > +	link_opts.kprobe_multi.syms = &sym;
> > +	/* MAX_KPROBE_MULTI_CNT is defined as (1U << 20) in kernel/trace/bpf_trace.c,
> > +	 * so we create one more than the allowed limit to make it fail with E2BIG.
> > +	 */
> > +	link_opts.kprobe_multi.cnt = (1U << 20) + 1;
> > +	link_fd = bpf_link_create(prog_fd, -1, BPF_TRACE_KPROBE_MULTI, &link_opts);
> > +	err = -errno;
> > +	if (link_fd >= 0)
> > +		close(link_fd);
> > +	close(prog_fd);
> > +	/* Fails with E2BIG on kernels where kprobe_multi is supported */
> > +	return link_fd <= 0 && err == -E2BIG;
>                     ^^^^
> 
> Should this be "link_fd < 0" rather than "link_fd <= 0"?  The
> reference function probe_uprobe_multi_link() just above uses
> "link_fd < 0 && err == -EINVAL" for the same pattern.  fd 0 is
> a valid file descriptor, so "<= 0" treats a successful fd 0 as
> a failure.  In practice bpf_link_create() goes through
> ensure_good_fd() which dup's fds below 3, so fd 0 cannot be
> returned, but the check is still inconsistent with the
> existing code pattern.

Good catch. I'll fix this in the next version after I get more reviews on this.

> > +}
> 
> [ ... ]
> 
> 
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> 
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23947048141

Re: [RFC PATCH bpf-next v3 3/3] libbpf: Auto-upgrade kprobes to multi-kprobes when supported

[Varun R Mallya]

On Fri, Apr 03, 2026 at 01:35:31PM +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > index bc749b9c291e..f566527d95f3 100644
> > --- a/tools/lib/bpf/libbpf.c
> > +++ b/tools/lib/bpf/libbpf.c
> 
> [ ... ]
> 
> > @@ -11841,6 +11867,30 @@ bpf_program__attach_kprobe_opts(const struct bpf_program *prog,
> >  	offset = OPTS_GET(opts, offset, 0);
> >  	pe_opts.bpf_cookie = OPTS_GET(opts, bpf_cookie, 0);
> >
> > +	/* This provides backwards compatibility to programs using kprobe, but
> > +	 * have been auto-upgraded to multi kprobe.
> > +	 */
> > +	if (prog->expected_attach_type == BPF_TRACE_KPROBE_MULTI &&
> > +	    offset == 0 && attach_mode == PROBE_ATTACH_MODE_DEFAULT) {
> 
> [ ... ]
> 
> > +	if (prog->expected_attach_type == BPF_TRACE_KPROBE_MULTI) {
> > +		pr_warn("prog '%s': multi-kprobe upgrade failed (off=%lu, mode=%d); use SEC(\"kprobe.single\")\n",
> > +			prog->name, offset, attach_mode);
> 
> Should this use %zu instead of %lu for offset?  It is declared as
> size_t in this function, and the existing pr_warn() calls further
> down use %zx for the same variable.

Valid, I'll do that too.

> > +		return libbpf_err_ptr(-ENOTSUP);
> > +	}
> 
> [ ... ]
> 
> > @@ -12297,14 +12347,24 @@ static int attach_kprobe(const struct bpf_program *prog, long cookie, struct bpf
> >  	*link = NULL;
> >
> >  	/* no auto-attach for SEC("kprobe") and SEC("kretprobe") */
> > -	if (strcmp(prog->sec_name, "kprobe") == 0 || strcmp(prog->sec_name, "kretprobe") == 0)
> > +	if (strcmp(prog->sec_name, "kprobe") == 0 ||
> > +	    strcmp(prog->sec_name, "kretprobe") == 0 ||
> > +	    strcmp(prog->sec_name, "kprobe.single") == 0 ||
> > +	    strcmp(prog->sec_name, "kretprobe.single") == 0)
> >  		return 0;
> 
> The comment above still only mentions SEC("kprobe") and
> SEC("kretprobe").  Could it be updated to also mention the .single
> variants that are now handled here?
> 

This seems valid, I'll add this into the next version.

> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> 
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23947048141