From: Yonghong Song <yonghong.song@linux.dev>
To: Varun R Mallya <varunrmallya@gmail.com>,
andrii@kernel.org, alan.maguire@oracle.com
Cc: ast@kernel.org, daniel@iogearbox.net, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH bpf-next 1/1] libbpf: Auto-upgrade uprobes to multi-uprobes when supported
Date: Thu, 12 Feb 2026 16:06:22 -0800 [thread overview]
Message-ID: <82d31503-24d8-45b8-b1dd-2cb35bd28509@linux.dev> (raw)
In-Reply-To: <20260212152013.17351-2-varunrmallya@gmail.com>
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.
>
> Signed-off-by: Varun R Mallya <varunrmallya@gmail.com>
> ---
> tools/lib/bpf/libbpf.c | 42 ++++++++++++++++++++++++++++++++++++------
> 1 file changed, 36 insertions(+), 6 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 0c8bf0b5cce4..a32f221d3245 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -8265,6 +8265,22 @@ static int bpf_object_init_progs(struct bpf_object *obj, const struct bpf_object
> prog->type = prog->sec_def->prog_type;
> prog->expected_attach_type = prog->sec_def->expected_attach_type;
>
> + /* set BPF_TRACE_UPROBE_MULTI if sec_name matches "u[ret]probe"
> + * otherwise, leave alone.
> + */
> + if (kernel_supports(obj, FEAT_UPROBE_MULTI_LINK)) {
> + char *probe_type = NULL;
> + int n;
> +
> + n = sscanf(prog->sec_name, "%m[^/]", &probe_type);
> + if (n >= 1)
> + if (!strcmp(probe_type, "uprobe") ||
> + !strcmp(probe_type, "uretprobe"))
> + prog->expected_attach_type = BPF_TRACE_UPROBE_MULTI;
> +
> + free(probe_type);
> + }
> +
> /* sec_def can have custom callback which should be called
> * after bpf_program is initialized to adjust its properties
> */
> @@ -9822,9 +9838,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),
> @@ -12722,10 +12740,10 @@ bpf_program__attach_uprobe_opts(const struct bpf_program *prog, pid_t pid,
> */
> static int attach_uprobe(const struct bpf_program *prog, long cookie, struct bpf_link **link)
> {
> - DECLARE_LIBBPF_OPTS(bpf_uprobe_opts, opts);
> char *probe_type = NULL, *binary_path = NULL, *func_name = NULL, *func_off;
> int n, c, ret = -EINVAL;
> long offset = 0;
> + bool is_retprobe;
>
> *link = NULL;
>
> @@ -12752,15 +12770,27 @@ static int attach_uprobe(const struct bpf_program *prog, long cookie, struct bpf
> else
> offset = 0;
> }
> - opts.retprobe = strcmp(probe_type, "uretprobe") == 0 ||
> - strcmp(probe_type, "uretprobe.s") == 0;
> - if (opts.retprobe && offset != 0) {
> + is_retprobe = strcmp(probe_type, "uretprobe") == 0 ||
> + strcmp(probe_type, "uretprobe.s") == 0;
> + if (is_retprobe && offset != 0) {
> pr_warn("prog '%s': uretprobes do not support offset specification\n",
> prog->name);
> break;
> }
> - opts.func_name = func_name;
> - *link = bpf_program__attach_uprobe_opts(prog, -1, binary_path, offset, &opts);
> + if (prog->expected_attach_type == BPF_TRACE_UPROBE_MULTI) {
> + DECLARE_LIBBPF_OPTS(bpf_uprobe_multi_opts, opts);
> +
> + opts.retprobe = is_retprobe;
> + *link = bpf_program__attach_uprobe_multi(prog, -1, binary_path,
> + func_name, &opts);
> + } else {
> + DECLARE_LIBBPF_OPTS(bpf_uprobe_opts, opts);
> +
> + opts.retprobe = is_retprobe;
> + opts.func_name = func_name;
> + *link = bpf_program__attach_uprobe_opts(prog, -1, binary_path,
> + offset, &opts);
> + }
> ret = libbpf_get_error(*link);
> break;
> default:
next prev parent reply other threads:[~2026-02-13 0:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-12 15:20 [RFC PATCH bpf-next 0/1] Upgrading uprobe and kprobe to their `multi` counterparts Varun R Mallya
2026-02-12 15:20 ` [RFC PATCH bpf-next 1/1] libbpf: Auto-upgrade uprobes to multi-uprobes when supported Varun R Mallya
2026-02-13 0:06 ` Yonghong Song [this message]
2026-02-13 17:22 ` Varun R Mallya
2026-02-14 5:25 ` Yonghong Song
2026-02-18 19:07 ` Andrii Nakryiko
2026-02-19 5:31 ` Yonghong Song
2026-02-18 19:03 ` Andrii Nakryiko
2026-02-18 19:07 ` [RFC PATCH bpf-next 0/1] Upgrading uprobe and kprobe to their `multi` counterparts Andrii Nakryiko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=82d31503-24d8-45b8-b1dd-2cb35bd28509@linux.dev \
--to=yonghong.song@linux.dev \
--cc=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=linux-kernel@vger.kernel.org \
--cc=varunrmallya@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox