From: Jiri Olsa <olsajiri@gmail.com>
To: Feng Yang <yangfeng59949@163.com>
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
martin.lau@linux.dev, eddyz87@gmail.com, song@kernel.org,
yonghong.song@linux.dev, john.fastabend@gmail.com,
kpsingh@kernel.org, sdf@fomichev.me, haoluo@google.com,
hengqi.chen@gmail.com, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 bpf-next 1/3] libbpf: Fix event name too long error
Date: Mon, 14 Apr 2025 13:43:38 +0200 [thread overview]
Message-ID: <Z_z06uND92kzrXfJ@krava> (raw)
In-Reply-To: <20250414093402.384872-2-yangfeng59949@163.com>
On Mon, Apr 14, 2025 at 05:34:00PM +0800, Feng Yang wrote:
> From: Feng Yang <yangfeng@kylinos.cn>
>
> When the binary path is excessively long, the generated probe_name in libbpf
> exceeds the kernel's MAX_EVENT_NAME_LEN limit (64 bytes).
> This causes legacy uprobe event attachment to fail with error code -22.
>
> Before Fix:
> ./test_progs -t attach_probe/kprobe-long_name
> ......
> libbpf: failed to add legacy kprobe event for 'bpf_kfunc_looooooooooooooooooooooooooooooong_name+0x0': -EINVAL
> libbpf: prog 'handle_kprobe': failed to create kprobe 'bpf_kfunc_looooooooooooooooooooooooooooooong_name+0x0' perf event: -EINVAL
> test_attach_kprobe_long_event_name:FAIL:attach_kprobe_long_event_name unexpected error: -22
> test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec
> #13/11 attach_probe/kprobe-long_name:FAIL
> #13 attach_probe:FAIL
>
> ./test_progs -t attach_probe/uprobe-long_name
> ......
> libbpf: failed to add legacy uprobe event for /root/linux-bpf/bpf-next/tools/testing/selftests/bpf/test_progs:0x13efd9: -EINVAL
> libbpf: prog 'handle_uprobe': failed to create uprobe '/root/linux-bpf/bpf-next/tools/testing/selftests/bpf/test_progs:0x13efd9' perf event: -EINVAL
> test_attach_uprobe_long_event_name:FAIL:attach_uprobe_long_event_name unexpected error: -22
> #13/10 attach_probe/uprobe-long_name:FAIL
> #13 attach_probe:FAIL
> After Fix:
> ./test_progs -t attach_probe/uprobe-long_name
> #13/10 attach_probe/uprobe-long_name:OK
> #13 attach_probe:OK
> Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED
>
> ./test_progs -t attach_probe/kprobe-long_name
> #13/11 attach_probe/kprobe-long_name:OK
> #13 attach_probe:OK
> Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED
>
> Fixes: 46ed5fc33db9 ("libbpf: Refactor and simplify legacy kprobe code")
> Fixes: cc10623c6810 ("libbpf: Add legacy uprobe attaching support")
> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
> Signed-off-by: Feng Yang <yangfeng@kylinos.cn>
> ---
> tools/lib/bpf/libbpf.c | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index b2591f5cab65..9e047641e001 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -60,6 +60,8 @@
> #define BPF_FS_MAGIC 0xcafe4a11
> #endif
>
> +#define MAX_EVENT_NAME_LEN 64
> +
> #define BPF_FS_DEFAULT_PATH "/sys/fs/bpf"
>
> #define BPF_INSN_SZ (sizeof(struct bpf_insn))
> @@ -11142,10 +11144,10 @@ static void gen_kprobe_legacy_event_name(char *buf, size_t buf_sz,
> static int index = 0;
> int i;
>
> - snprintf(buf, buf_sz, "libbpf_%u_%s_0x%zx_%d", getpid(), kfunc_name, offset,
> - __sync_fetch_and_add(&index, 1));
> + snprintf(buf, buf_sz, "libbpf_%u_%d_%s_0x%zx", getpid(),
> + __sync_fetch_and_add(&index, 1), kfunc_name, offset);
so the fix is to move unique id before kfunc_name to make sure it gets
to the event name right? would be great to have it in changelog
>
> - /* sanitize binary_path in the probe name */
> + /* sanitize kfunc_name in the probe name */
> for (i = 0; buf[i]; i++) {
> if (!isalnum(buf[i]))
> buf[i] = '_';
> @@ -11270,7 +11272,7 @@ int probe_kern_syscall_wrapper(int token_fd)
>
> return pfd >= 0 ? 1 : 0;
> } else { /* legacy mode */
> - char probe_name[128];
> + char probe_name[MAX_EVENT_NAME_LEN];
>
> gen_kprobe_legacy_event_name(probe_name, sizeof(probe_name), syscall_name, 0);
> if (add_kprobe_event_legacy(probe_name, false, syscall_name, 0) < 0)
> @@ -11328,7 +11330,7 @@ bpf_program__attach_kprobe_opts(const struct bpf_program *prog,
> func_name, offset,
> -1 /* pid */, 0 /* ref_ctr_off */);
> } else {
> - char probe_name[256];
> + char probe_name[MAX_EVENT_NAME_LEN];
>
> gen_kprobe_legacy_event_name(probe_name, sizeof(probe_name),
> func_name, offset);
> @@ -11878,9 +11880,12 @@ static int attach_uprobe_multi(const struct bpf_program *prog, long cookie, stru
> static void gen_uprobe_legacy_event_name(char *buf, size_t buf_sz,
> const char *binary_path, uint64_t offset)
> {
> + static int index = 0;
> int i;
>
> - snprintf(buf, buf_sz, "libbpf_%u_%s_0x%zx", getpid(), binary_path, (size_t)offset);
> + snprintf(buf, buf_sz, "libbpf_%u_%d_%s_0x%zx", getpid(),
> + __sync_fetch_and_add(&index, 1),
> + basename((void *)binary_path), (size_t)offset);
gen_kprobe_legacy_event_name and gen_uprobe_legacy_event_name seem to
be identical now, maybe we can have just one ?
thanks,
jirka
>
> /* sanitize binary_path in the probe name */
> for (i = 0; buf[i]; i++) {
> @@ -12312,7 +12317,7 @@ bpf_program__attach_uprobe_opts(const struct bpf_program *prog, pid_t pid,
> pfd = perf_event_open_probe(true /* uprobe */, retprobe, binary_path,
> func_offset, pid, ref_ctr_off);
> } else {
> - char probe_name[PATH_MAX + 64];
> + char probe_name[MAX_EVENT_NAME_LEN];
>
> if (ref_ctr_off)
> return libbpf_err_ptr(-EINVAL);
> --
> 2.43.0
>
next prev parent reply other threads:[~2025-04-14 11:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-14 9:33 [PATCH v3 bpf-next 0/3] libbpf: Fix event name too long error and add tests Feng Yang
2025-04-14 9:34 ` [PATCH v3 bpf-next 1/3] libbpf: Fix event name too long error Feng Yang
2025-04-14 11:43 ` Jiri Olsa [this message]
2025-04-15 2:01 ` Feng Yang
2025-04-15 7:20 ` Jiri Olsa
2025-04-14 9:34 ` [PATCH v3 bpf-next 2/3] selftests/bpf: Add test for attaching uprobe with long event names Feng Yang
2025-04-14 9:34 ` [PATCH v3 bpf-next 3/3] selftests/bpf: Add test for attaching kprobe " Feng Yang
2025-04-14 11:47 ` Jiri Olsa
2025-04-15 2:52 ` Feng Yang
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=Z_z06uND92kzrXfJ@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=haoluo@google.com \
--cc=hengqi.chen@gmail.com \
--cc=john.fastabend@gmail.com \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=yangfeng59949@163.com \
--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