All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: sashiko-reviews@lists.linux.dev
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 3/3] bpftool: Add tracing_multi link info output
Date: Mon, 22 Jun 2026 12:35:52 +0200	[thread overview]
Message-ID: <ajkQCLW3k0cIEuut@krava> (raw)
In-Reply-To: <20260621205628.2920D1F000E9@smtp.kernel.org>

On Sun, Jun 21, 2026 at 08:56:27PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Repeated parsing of `/proc/kallsyms` in an O(N) loop when symbol loading fails.
> --
> 
> commit 0f11f8e705a95b6aa483a05374ffb9b22bcb78c0
> Author: Jiri Olsa <jolsa@kernel.org>
> 
> bpftool: Add tracing_multi link info output
> 
> This commit adds bpftool support to show tracing_multi link details for both
> plain and JSON outputs.
> 
> > diff --git a/tools/bpf/bpftool/link.c b/tools/bpf/bpftool/link.c
> > index bdcd717b0348f..58dadee984a07 100644
> > --- a/tools/bpf/bpftool/link.c
> > +++ b/tools/bpf/bpftool/link.c
> > @@ -377,6 +377,31 @@ static __u64 *u64_to_arr(__u64 val)
> >  	return (__u64 *) u64_to_ptr(val);
> >  }
> >  
> > +static __u32 *u64_to_u32_arr(__u64 val)
> > +{
> > +	return (__u32 *)u64_to_ptr(val);
> > +}
> > +
> > +static struct kernel_sym *find_kernel_sym_by_addr(__u64 addr, bool is_ibt_enabled)
> > +{
> > +	struct kernel_sym *sym;
> > +
> > +	if (!addr)
> > +		return NULL;
> > +
> > +	/* Load it once for all. */
> > +	if (!dd.sym_count)
> > +		kernel_syms_load(&dd);
> > +	if (!dd.sym_count)
> > +		return NULL;
> > +
> > +	sym = kernel_syms_search(&dd, addr);
> > +	if (!sym && is_ibt_enabled && addr >= 4)
> > +		sym = kernel_syms_search(&dd, addr - 4);
> > +
> > +	return sym;
> > +}
> 
> [ ... ]
> 
> > @@ -403,6 +428,43 @@ show_uprobe_multi_json(struct bpf_link_info *info, json_writer_t *wtr)
> >  	jsonw_end_array(json_wtr);
> >  }
> >  
> > +static void
> > +show_tracing_multi_json(struct bpf_link_info *info, json_writer_t *wtr)
> > +{
> > +	bool is_ibt_enabled = is_x86_ibt_enabled();
> > +	__u32 i;
> > +
> > +	show_link_attach_type_json(info->tracing_multi.attach_type, wtr);
> > +	jsonw_uint_field(wtr, "func_cnt", info->tracing_multi.count);
> > +	jsonw_uint_field(wtr, "obj_id", info->tracing_multi.obj_id);
> > +	jsonw_name(wtr, "funcs");
> > +
> > +	jsonw_start_array(wtr);
> > +
> > +	for (i = 0; i < info->tracing_multi.count; i++) {
> > +		__u64 addr = u64_to_arr(info->tracing_multi.addrs)[i];
> > +		struct kernel_sym *sym;
> > +
> > +		sym = find_kernel_sym_by_addr(addr, is_ibt_enabled);
> 
> [Severity: Medium]
> If kernel_syms_load() fails (for example, due to kernel.kptr_restrict or
> a lack of read permissions for /proc/kallsyms), dd.sym_count remains 0.
> 
> Since find_kernel_sym_by_addr() checks !dd.sym_count to decide whether to load
> symbols, won't this cause /proc/kallsyms to be repeatedly opened and parsed on
> every iteration of this loop if the initial load fails?
> 
> This loop occurs here in show_tracing_multi_json() as well as in
> show_tracing_multi_plain(). For tracing_multi links with potentially thousands
> of targets, could this result in a significant performance hang for bpftool?

ok, I think we can make sure the parsing happens just once with
the change below, will do that in next version

jirka


---
diff --git a/tools/bpf/bpftool/link.c b/tools/bpf/bpftool/link.c
index 58dadee984a0..db780ee39820 100644
--- a/tools/bpf/bpftool/link.c
+++ b/tools/bpf/bpftool/link.c
@@ -389,12 +389,6 @@ static struct kernel_sym *find_kernel_sym_by_addr(__u64 addr, bool is_ibt_enable
 	if (!addr)
 		return NULL;
 
-	/* Load it once for all. */
-	if (!dd.sym_count)
-		kernel_syms_load(&dd);
-	if (!dd.sym_count)
-		return NULL;
-
 	sym = kernel_syms_search(&dd, addr);
 	if (!sym && is_ibt_enabled && addr >= 4)
 		sym = kernel_syms_search(&dd, addr - 4);
@@ -431,9 +425,13 @@ show_uprobe_multi_json(struct bpf_link_info *info, json_writer_t *wtr)
 static void
 show_tracing_multi_json(struct bpf_link_info *info, json_writer_t *wtr)
 {
-	bool is_ibt_enabled = is_x86_ibt_enabled();
+	bool is_ibt_enabled = is_x86_ibt_enabled(), show_symbol;
 	__u32 i;
 
+	if (!dd.sym_count)
+		kernel_syms_load(&dd);
+	show_symbol = !!dd.sym_count;
+
 	show_link_attach_type_json(info->tracing_multi.attach_type, wtr);
 	jsonw_uint_field(wtr, "func_cnt", info->tracing_multi.count);
 	jsonw_uint_field(wtr, "obj_id", info->tracing_multi.obj_id);
@@ -445,7 +443,7 @@ show_tracing_multi_json(struct bpf_link_info *info, json_writer_t *wtr)
 		__u64 addr = u64_to_arr(info->tracing_multi.addrs)[i];
 		struct kernel_sym *sym;
 
-		sym = find_kernel_sym_by_addr(addr, is_ibt_enabled);
+		sym = show_symbol ? find_kernel_sym_by_addr(addr, is_ibt_enabled) : NULL;
 
 		jsonw_start_object(wtr);
 		jsonw_uint_field(wtr, "id", u64_to_u32_arr(info->tracing_multi.ids)[i]);
@@ -900,12 +898,16 @@ static void show_uprobe_multi_plain(struct bpf_link_info *info)
 
 static void show_tracing_multi_plain(struct bpf_link_info *info)
 {
-	bool is_ibt_enabled = is_x86_ibt_enabled();
+	bool is_ibt_enabled = is_x86_ibt_enabled(), show_symbol;
 	__u32 i;
 
 	if (!info->tracing_multi.count)
 		return;
 
+	if (!dd.sym_count)
+		kernel_syms_load(&dd);
+	show_symbol = !!dd.sym_count;
+
 	printf("\n\t");
 	show_link_attach_type_plain(info->tracing_multi.attach_type);
 	printf("obj_id %u  ", info->tracing_multi.obj_id);
@@ -917,7 +919,7 @@ static void show_tracing_multi_plain(struct bpf_link_info *info)
 		__u64 addr = u64_to_arr(info->tracing_multi.addrs)[i];
 		struct kernel_sym *sym;
 
-		sym = find_kernel_sym_by_addr(addr, is_ibt_enabled);
+		sym = show_symbol ? find_kernel_sym_by_addr(addr, is_ibt_enabled) : NULL;
 
 		printf("\n\t%-16u %016llx %-16llx",
 		       u64_to_u32_arr(info->tracing_multi.ids)[i],

      reply	other threads:[~2026-06-22 10:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-21 20:45 [PATCH bpf-next 0/3] bpf: tracing_multi link info support Jiri Olsa
2026-06-21 20:45 ` [PATCH bpf-next 1/3] bpf: Add " Jiri Olsa
2026-06-21 20:45 ` [PATCH bpf-next 2/3] selftests/bpf: Add tracing_multi link info tests Jiri Olsa
2026-06-21 20:53   ` sashiko-bot
2026-06-22 10:35     ` Jiri Olsa
2026-06-21 21:31   ` bot+bpf-ci
2026-06-22 10:36     ` Jiri Olsa
2026-06-21 20:45 ` [PATCH bpf-next 3/3] bpftool: Add tracing_multi link info output Jiri Olsa
2026-06-21 20:56   ` sashiko-bot
2026-06-22 10:35     ` Jiri Olsa [this message]

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=ajkQCLW3k0cIEuut@krava \
    --to=olsajiri@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=sashiko-reviews@lists.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 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.