[PATCH] tools/perf/test: Check for perf stat return code in perf all PMU test

[Athira Rajeev]

> On 2 Apr 2026, at 5:27 AM, Ian Rogers <irogers at google.com> wrote:
> 
> On Wed, Apr 1, 2026 at 4:48 PM Namhyung Kim <namhyung at kernel.org> wrote:
>> 
>> On Wed, Apr 01, 2026 at 01:40:47PM -0700, Ian Rogers wrote:
>>> This looks like a latent Intel cpu_atom PMU bug. Thomas, wdyt?
>> 
>> Are you ok with the change itself then?
>> 
>> I'm not sure what's the expectation when the test runs with a regular
>> user.  I assume the intention of this change is running as root..
> 
> So the test is failing as root on Intel, and the log output is
> extensive. I'd prefer not to have the log output, so we may need to
> work past some known broken items. Otherwise, the change looks okay,
> but there are inconsistencies: `grep -q "<not supported>"` is used in
> the existing code, while `grep -q "not supported"` is used here.
> 
> Thanks,
> Ian
> 
>> Thanks,
>> Namhyung
>> 

Hi Namhyung, Ian

Thanks for trying the change and responding.

Sorry, I missed the comment from Sashiko. Next time I will check explicitly for Sashiko comments too.

The intention of this patch has two things:

1) It was resulting in “false pass” earlier if the test fallback to last check where we run with longer workload. Because error
  message contains the event name “$p” and hence matches the “grep” check. 

Example:

   # ./perf stat -e hv_24x7/CPM_ADJUNCT_PCYC/ ./perf bench internals synthesize
    event syntax error: 'hv_24x7/CPM_ADJUNCT_PCYC/'
                     \___ Bad event or PMU

    Unable to find PMU or event on a PMU of ‘hv_24x7'
    Run 'perf list' for a list of valid events

    Usage: perf stat [<options>] [<command>]

        -e, --event <event>   event selector. use 'perf list' to list available events
  # echo $?
     129


Here the test checks for :
  <<>>
   output=$(perf stat -e "$p" perf bench internals synthesize 2>&1)
   if echo "$output" | grep -q "$p”
  <<>>

Since the error message contains the event name, it matches grep check and declares test as pass.

 To catch this, patch adds a check for “return code” 

+  # checked through possible access limitations and permissions.
+  # At this step, non-zero return code from "perf stat" needs to
+  # reported as fail for the user to investigate
+  if [ $stat_result -ne 0 ]
+  then
+    echo "perf stat failed with non-zero return code"
+    err=1
+    continue
+  fi

2) If events are supported in system wide monitoring. 

Namhyung is right here that for regular user it will result in fail . I will take care of having check around that.
The reason for using “not supported” text here is:

Example: There is an event in powerpc "vpa_dtl/dtl_all/“ which when run on per thread monitoring:

 # ./perf stat  -e vpa_dtl/dtl_all/ true
    Error:  
    No supported events found.
    Unsupported event (vpa_dtl/dtl_all/H) in per-thread mode, enable system wide with '-a’.

Next running with system wide monitoring:

  # ./perf stat -a -e vpa_dtl/dtl_all/ true
     Error:
     No supported events found.
     The sys_perf_event_open() syscall failed for event (vpa_dtl/dtl_all/H): Operation not supported
     "dmesg | grep -i perf" may provide additional information.

This is because this event is supported for only “sampling” system wide and not counting. 
So patch attempts to use “-a”, if still it fails, we look for “not supported” in logs

Namhyung, Ian,

If the addition of “-a” can cause regression ( like intel one if its not suppose to be run system wide ), 
how about adding a case like this:
- Look for "enable system wide with '-a’ “ in the error logs
	- If logs matches this message and if user is root, attempt with -a next.
       - With “-a”, If the logs has "Operation not supported” , test can continue to next event.

Thanks
Athira