All of lore.kernel.org
 help / color / mirror / Atom feed
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:


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.