public inbox for linux-perf-users@vger.kernel.org
 help / color / mirror / Atom feed
From: Ian Rogers <irogers@google.com>
To: acme@kernel.org, namhyung@kernel.org
Cc: irogers@google.com, adrian.hunter@intel.com,
	 alexander.shishkin@linux.intel.com, collin.funk1@gmail.com,
	ctshao@google.com,  james.clark@linaro.org, jolsa@kernel.org,
	linux-kernel@vger.kernel.org,  linux-perf-users@vger.kernel.org,
	mingo@redhat.com, peterz@infradead.org
Subject: [PATCH v2] perf test: Fix inet_pton probe failure and unroll call graph
Date: Sat, 11 Apr 2026 12:37:05 -0700	[thread overview]
Message-ID: <20260411193705.735269-1-irogers@google.com> (raw)
In-Reply-To: <20260410002351.10856-1-irogers@google.com>

When adding a probe for libc's inet_pton, perf probe may create multiple
probe points (e.g., due to inlining or multiple symbol resolutions),
resulting in multiple identical event names being output (e.g.,
`probe_libc:inet_pton_1`).

The script previously used a brittle pipeline (`tail -n +2 | head -n -5`)
and an awk script to extract the event name. When multiple probes were
added, awk would output the event name multiple times, which expanded
to multiple words in bash. This broke the subsequent `perf record` and
`perf probe -d` commands, causing the test to fail with:
`Error: another command except --add is set.`

Fix this by removing the brittle `tail/head` commands and appending
`| head -n 1` to the awk extraction. This ensures that only a single,
unique event name is captured, regardless of how many probe points
are created.

Additionally, the test artificially limited the backtrace size via
`max-stack=4` and did not specify dwarf call graphs for non-s390x
architectures. In newer libc versions where `inet_pton` is nested
deeper or compiled without frame pointers, `perf script` failed to resolve
the backtrace up to `/bin/ping`. Fix this by explicitly collecting
dwarf call-graphs for all architectures and increasing `max-stack` to 8.

Assisted-by: Gemini:gemini-3.1-pro-preview
Signed-off-by: Ian Rogers <irogers@google.com>
---
 tools/perf/tests/shell/record+probe_libc_inet_pton.sh | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/perf/tests/shell/record+probe_libc_inet_pton.sh b/tools/perf/tests/shell/record+probe_libc_inet_pton.sh
index ab99bef556bf..eca629ee83f0 100755
--- a/tools/perf/tests/shell/record+probe_libc_inet_pton.sh
+++ b/tools/perf/tests/shell/record+probe_libc_inet_pton.sh
@@ -22,9 +22,9 @@ event_pattern='probe_libc:inet_pton(_[[:digit:]]+)?'
 
 add_libc_inet_pton_event() {
 
-	event_name=$(perf probe -f -x $libc -a inet_pton 2>&1 | tail -n +2 | head -n -5 | \
+	event_name=$(perf probe -f -x $libc -a inet_pton 2>&1 | \
 			awk -v ep="$event_pattern" -v l="$libc" '$0 ~ ep && $0 ~ \
-			("\\(on inet_pton in " l "\\)") {print $1}')
+			("\\(on inet_pton in " l "\\)") {print $1}' | head -n 1)
 
 	if [ $? -ne 0 ] || [ -z "$event_name" ] ; then
 		printf "FAIL: could not add event\n"
@@ -40,12 +40,12 @@ trace_libc_inet_pton_backtrace() {
 	echo ".*inet_pton\+0x[[:xdigit:]]+[[:space:]]\($libc|inlined\)$" >> $expected
 	case "$(uname -m)" in
 	s390x)
-		eventattr='call-graph=dwarf,max-stack=4'
+		eventattr='call-graph=dwarf,max-stack=8'
 		echo "((__GI_)?getaddrinfo|text_to_binary_address)\+0x[[:xdigit:]]+[[:space:]]\($libc|inlined\)$" >> $expected
 		echo "(gaih_inet|main)\+0x[[:xdigit:]]+[[:space:]]\(inlined|.*/bin/ping.*\)$" >> $expected
 		;;
 	*)
-		eventattr='max-stack=4'
+		eventattr='call-graph=dwarf,max-stack=8'
 		echo ".*(\+0x[[:xdigit:]]+|\[unknown\])[[:space:]]\(.*/bin/ping.*\)$" >> $expected
 		;;
 	esac
-- 
2.53.0.1213.gd9a14994de-goog


  parent reply	other threads:[~2026-04-11 19:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-10  0:23 [PATCH v1] perf test: Fix inet_pton probe failure due to multiple probes Ian Rogers
2026-04-10  0:38 ` sashiko-bot
2026-04-11 19:37 ` Ian Rogers [this message]
2026-04-11 19:54   ` [PATCH v2] perf test: Fix inet_pton probe failure and unroll call graph sashiko-bot
2026-04-12  1:14     ` Ian Rogers

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=20260411193705.735269-1-irogers@google.com \
    --to=irogers@google.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=collin.funk1@gmail.com \
    --cc=ctshao@google.com \
    --cc=james.clark@linaro.org \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    /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