public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: Hoyeon Lee <hoyeon.lee@suse.com>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	Shuah Khan <shuah@kernel.org>, Feng Yang <yangfeng@kylinos.cn>,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 1/2] libbpf: allow address-based single kprobe attach
Date: Mon, 30 Mar 2026 12:08:08 +0200	[thread overview]
Message-ID: <acpLiCDwAtn8xLjs@krava> (raw)
In-Reply-To: <20260329124429.689912-2-hoyeon.lee@suse.com>

On Sun, Mar 29, 2026 at 09:43:38PM +0900, Hoyeon Lee wrote:
> bpf_program__attach_kprobe_opts() currently attaches a single kprobe only
> by func_name, with an optional offset. This covers only the symbol-
> based form, not the raw-address form that the kernel already supports
> for both kprobe PMU events and legacy tracefs/debugfs kprobes. Callers
> that already have a target IP still have to drop down to
> perf_event_open() or direct tracefs writes.
> 
> libbpf already exposes address-based attach for kprobe_multi through
> bpf_kprobe_multi_opts.addrs. This commit adds bpf_kprobe_opts.addr so
> that single kprobes can be attached either by func_name + offset or by
> raw address.

curious, is this change just for the api to be complete or you do have
a usecase where you can't use kprobe_multi and need to attach kprobe
by address?

SNIP

>  static void gen_probe_legacy_event_name(char *buf, size_t buf_sz,
> -					const char *name, size_t offset)
> +					const char *name,
> +					uint64_t offset_or_addr)
>  {
>  	static int index = 0;
>  	int i;
>  
> -	snprintf(buf, buf_sz, "libbpf_%u_%d_%s_0x%zx", getpid(),
> -		 __sync_fetch_and_add(&index, 1), name, offset);
> +	snprintf(buf, buf_sz, "libbpf_%u_%d_%s_0x%" PRIx64, getpid(),
> +		 __sync_fetch_and_add(&index, 1), name ?: "addr",
> +		 offset_or_addr);
>  
>  	/* sanitize name in the probe name */
>  	for (i = 0; buf[i]; i++) {
> @@ -11648,13 +11651,28 @@ static void gen_probe_legacy_event_name(char *buf, size_t buf_sz,
>  	}
>  }
>  
> +static void gen_kprobe_target(char *buf, size_t buf_sz, const char *name,
> +			      uint64_t offset_or_addr)
> +{
> +	if (name)
> +		snprintf(buf, buf_sz, "%s+0x%" PRIx64, name, offset_or_addr);
> +	else
> +		snprintf(buf, buf_sz, "0x%" PRIx64, offset_or_addr);
> +}
> +
>  static int add_kprobe_event_legacy(const char *probe_name, bool retprobe,
> -				   const char *kfunc_name, size_t offset)
> +				   const char *kfunc_name,
> +				   uint64_t offset_or_addr)
>  {
> -	return append_to_file(tracefs_kprobe_events(), "%c:%s/%s %s+0x%zx",
> +	char probe_target[128];
> +
> +	gen_kprobe_target(probe_target, sizeof(probe_target), kfunc_name,
> +			  offset_or_addr);
> +

it seems like it'd be easier to get probe_target (via gen_kprobe_target)
in bpf_program__attach_kprobe_opts and pass it down instead of generating
it over and over again

> +	return append_to_file(tracefs_kprobe_events(), "%c:%s/%s %s",
>  			      retprobe ? 'r' : 'p',
>  			      retprobe ? "kretprobes" : "kprobes",
> -			      probe_name, kfunc_name, offset);
> +			      probe_name, probe_target);
>  }
>  
>  static int remove_kprobe_event_legacy(const char *probe_name, bool retprobe)
> @@ -11674,25 +11692,29 @@ static int determine_kprobe_perf_type_legacy(const char *probe_name, bool retpro
>  }
>  
>  static int perf_event_kprobe_open_legacy(const char *probe_name, bool retprobe,
> -					 const char *kfunc_name, size_t offset, int pid)
> +					 const char *kfunc_name,
> +					 uint64_t offset_or_addr, int pid)
>  {
>  	const size_t attr_sz = sizeof(struct perf_event_attr);
>  	struct perf_event_attr attr;
>  	int type, pfd, err;
> +	char probe_target[128];

we need bigger buffer as explained by sashiko [1]

[1] https://sashiko.dev/#/patchset/20260329124429.689912-1-hoyeon.lee%40suse.com

jirka

>  
> -	err = add_kprobe_event_legacy(probe_name, retprobe, kfunc_name, offset);
> +	gen_kprobe_target(probe_target, sizeof(probe_target), kfunc_name,
> +			  offset_or_addr);
> +
> +	err = add_kprobe_event_legacy(probe_name, retprobe, kfunc_name,
> +				      offset_or_addr);
>  	if (err < 0) {
> -		pr_warn("failed to add legacy kprobe event for '%s+0x%zx': %s\n",
> -			kfunc_name, offset,
> -			errstr(err));
> +		pr_warn("failed to add legacy kprobe event for '%s': %s\n",
> +			probe_target, errstr(err));
>  		return err;
>  	}
>  	type = determine_kprobe_perf_type_legacy(probe_name, retprobe);
>  	if (type < 0) {
>  		err = type;
> -		pr_warn("failed to determine legacy kprobe event id for '%s+0x%zx': %s\n",
> -			kfunc_name, offset,
> -			errstr(err));
> +		pr_warn("failed to determine legacy kprobe event id for '%s': %s\n",
> +			probe_target, errstr(err));
>  		goto err_clean_legacy;
>  	}
>  

SNIP

  reply	other threads:[~2026-03-30 10:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-29 12:43 [PATCH bpf-next v2 0/2] libbpf: allow address-based single kprobe attach Hoyeon Lee
2026-03-29 12:43 ` [PATCH bpf-next v2 1/2] " Hoyeon Lee
2026-03-30 10:08   ` Jiri Olsa [this message]
2026-03-31  1:47     ` Hoyeon Lee
2026-03-31  0:33   ` Andrii Nakryiko
2026-03-31  1:48     ` Hoyeon Lee
2026-03-31  2:15       ` Alexei Starovoitov
2026-03-31  5:55         ` Hoyeon Lee
2026-03-29 12:43 ` [PATCH bpf-next v2 2/2] selftests/bpf: add test for " Hoyeon Lee
2026-03-30 10:08   ` Jiri Olsa
2026-03-31  2:01     ` Hoyeon Lee

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=acpLiCDwAtn8xLjs@krava \
    --to=olsajiri@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=hoyeon.lee@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=memxor@gmail.com \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=yangfeng@kylinos.cn \
    --cc=yonghong.song@linux.dev \
    /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