[PATCH] perf test: perftool-testsuite-report fails on s390

[PATCH] perf test: perftool-testsuite-report fails on s390

[Thomas Richter]

Test case perftool-testsuite-report.sh always fails on s390.
Root cause is a default timeout for addr2line command which is too
short for s390. Function cmd_addr2line() invokes addr2line command
and reads via pipe the function name on stdout, after writing
an address to stdin. There is a default timeout for the expected
reply, but very often this timeout is too short and nothing is
returned. This leads to the error message listed in
util/addr2line.c:

   switch (read_addr2line_record(&io, cmd_a2l_style, dso_name, ..) {
   case -1:
          if (!symbol_conf.addr2line_disable_warn)
                 pr_warning("%s %s: could not read first record\n",
				   ...)
          goto out;
   ...

As the test case emits warnings, it is reported as failed.
Fix this for s390 and create a temporary perf configuration file to
suppress these warnings. (An alternative would be to increase
the default timeout to a larger value).

Output before:
 # bash perftool-testsuite_report.sh
 -- [ PASS ] -- perf_report :: setup :: prepare the perf.data file
 ==================
 [ perf record: Woken up 1 times to write data ]
 [ perf record: Captured and wrote 0.087 MB (402 samples) ]
 ==================
 -- [ PASS ] -- perf_report :: setup :: prepare the perf.data.1 file
 ## [ PASS ] ## perf_report :: setup SUMMARY
 -- [ SKIP ] -- perf_report :: test_basic :: help message :: \
 		testcase skipped
 Line did not match any pattern: "cmd__addr2line <file> could not \
	read first record"
 -- [ FAIL ] -- perf_report :: test_basic :: basic execution \
	 (output regexp parsing)
 Line did not match any pattern: "cmd__addr2line <file> could not \
	read first record"
 ...
 ## [ FAIL ] ## perf_report :: test_basic SUMMARY :: 6 failures found

All six tests fail for the same reason, addr2line did not respond in
time.

Output after:
 # bash perftool-testsuite_report.sh
 -- [ PASS ] -- perf_report :: setup :: prepare the perf.data file
 ==================
 [ perf record: Woken up 1 times to write data ]
 [ perf record: Captured and wrote 0.086 MB .... (380 samples) ]
 ==================
 -- [ PASS ] -- perf_report :: setup :: prepare the perf.data.1 file
 ## [ PASS ] ## perf_report :: setup SUMMARY
 -- [ SKIP ] -- perf_report :: test_basic :: help message :: \
 				testcase skipped
 -- [ PASS ] -- perf_report :: test_basic :: basic execution
 -- [ PASS ] -- perf_report :: test_basic :: number of samples
 -- [ PASS ] -- perf_report :: test_basic :: header
 -- [ PASS ] -- perf_report :: test_basic :: header timestamp
 -- [ PASS ] -- perf_report :: test_basic :: show CPU utilization
 -- [ PASS ] -- perf_report :: test_basic :: pid
 -- [ PASS ] -- perf_report :: test_basic :: non-existing symbol
 -- [ PASS ] -- perf_report :: test_basic :: symbol filter
 -- [ PASS ] -- perf_report :: test_basic :: latency header
 -- [ PASS ] -- perf_report :: test_basic :: default report for \
						 latency profile
 -- [ PASS ] -- perf_report :: test_basic :: latency report for \
 						latency profile
 -- [ PASS ] -- perf_report :: test_basic :: parallelism histogram
 ## [ PASS ] ## perf_report :: test_basic SUMMARY
 #

Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Reviewed-by: Jan Polensky <japo@linux.ibm.com>
---
 tools/perf/tests/shell/perftool-testsuite_report.sh | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/tools/perf/tests/shell/perftool-testsuite_report.sh b/tools/perf/tests/shell/perftool-testsuite_report.sh
index a8cf75b4e77e..997573f0e74c 100755
--- a/tools/perf/tests/shell/perftool-testsuite_report.sh
+++ b/tools/perf/tests/shell/perftool-testsuite_report.sh
@@ -6,6 +6,14 @@ test -d "$(dirname "$0")/base_report" || exit 2
 cd "$(dirname "$0")/base_report" || exit 2
 status=0
 
+# On s390 the default timeout for addr2line is too short, disable warnings
+if [ $(uname -m) = s390x ]
+then
+	perf_config_tmp=$(mktemp /tmp/.perfconfig_XXXXX)
+	export PERF_CONFIG="${perf_config_tmp}"
+	perf config 'core.addr2line-disable-warn = true'
+fi
+
 PERFSUITE_RUN_DIR=$(mktemp -d /tmp/"$(basename "$0" .sh)".XXX)
 export PERFSUITE_RUN_DIR
 
@@ -19,5 +27,6 @@ if ! [ "$PERFTEST_KEEP_LOGS" = "y" ]; then
 	rm -rf "$PERFSUITE_RUN_DIR"
 fi
 
+rm -f "${perf_config_tmp}"
 test $status -ne 0 && exit 1
 exit 0
-- 
2.55.0

Re: [PATCH] perf test: perftool-testsuite-report fails on s390

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Uninitialized variable `perf_config_tmp` is passed to `rm -f`, leading to potential arbitrary file deletion via environment variable injection.
--

--- Patch [1]: [PATCH] perf test: perftool-testsuite-report fails on s390 ---
commit dcb55bb63ed0f15c0433bf20e85a5b7ffe77aedd
Author: Thomas Richter <tmricht@linux.ibm.com>

perf test: perftool-testsuite-report fails on s390

This commit fixes a test failure on s390 by creating a temporary perf
configuration file that disables addr2line warnings, working around a
timeout issue.

> diff --git a/tools/perf/tests/shell/perftool-testsuite_report.sh b/tools/perf/tests/shell/perftool-testsuite_report.sh
> index a8cf75b4e77ec..997573f0e74c5 100755
> --- a/tools/perf/tests/shell/perftool-testsuite_report.sh
> +++ b/tools/perf/tests/shell/perftool-testsuite_report.sh
> @@ -6,6 +6,14 @@ test -d "$(dirname "$0")/base_report" || exit 2
>  cd "$(dirname "$0")/base_report" || exit 2
>  status=0
>  
> +# On s390 the default timeout for addr2line is too short, disable warnings
> +if [ $(uname -m) = s390x ]
> +then
> +	perf_config_tmp=$(mktemp /tmp/.perfconfig_XXXXX)
> +	export PERF_CONFIG="${perf_config_tmp}"
> +	perf config 'core.addr2line-disable-warn = true'
> +fi
> +

[ ... ]

> @@ -19,5 +27,6 @@ if ! [ "$PERFTEST_KEEP_LOGS" = "y" ]; then
>  	rm -rf "$PERFSUITE_RUN_DIR"
>  fi
>  
> +rm -f "${perf_config_tmp}"

[Severity: Medium]
Is it possible for perf_config_tmp to be read from the environment on
non-s390x architectures?

Since perf_config_tmp is only initialized inside the s390x if-block above,
if this script runs on another architecture, the variable remains
uninitialized locally. Could an inherited environment variable of the same
name cause an unintended file to be deleted here?

Additionally, executing rm -f "" on non-s390x systems is sloppy and can
sometimes produce spurious errors depending on the rm implementation. Would
it be better to unconditionally initialize the variable to empty at the start
of the script, or check if it is set before calling rm?

>  test $status -ne 0 && exit 1
>  exit 0

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709062724.2663228-1-tmricht@linux.ibm.com?part=1