From: TAKANO Mitsuhiro <takano32@gmail.com>
To: linux-perf-users@vger.kernel.org,
Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>,
Ian Rogers <irogers@google.com>,
TAKANO Mitsuhiro <takano32@gmail.com>
Subject: [PATCH v3] perf stat: Start tool events when enable_on_exec is used
Date: Fri, 23 Oct 2026 10:12:56 +0000 [thread overview]
Message-ID: <20261023101256.1752713-1-takano32@gmail.com> (raw)
In-Reply-To: <20261023085554.1694434-1-takano32@gmail.com>
When perf stat runs a workload, target__enable_on_exec() is true and the
tool events are left to the kernel to start on exec. Tool events are
however emulated in perf (duration_time, user_time, system_time,
num_cpus) and have nothing in the kernel to start them, so they stay
disabled and are read as zero.
For duration_time this makes CPUs_utilized divide by zero, and plain
"perf stat" prints "nan CPUs":
$ perf stat -e task-clock,duration_time -- sleep 0.1
0 duration_time
Start the tool events explicitly in that case. They are started through
evsel__tool_pmu_enable() rather than evsel__enable(), because the latter
also enables the members of a mixed PMU group, and those cannot be used
here: get_group_fd() passes the leader's descriptor to
sys_perf_event_open(), which fails with EINVAL for a userspace PMU
leader, so the members end up unsupported with core.fd released. Only
the tool event itself is started; the kernel starts the members of a
group it can open.
Skip the events that failed to open, the same way the evlist and the
counter read paths skip them, so a tool event that never opened is not
started and then read through a NULL descriptor.
Fixes: 0b18bced5444 ("perf tool_pmu: Make tool PMU events respect enable/disable")
Assisted-by: LLM
---
v1 -> v2: Do not call evsel__enable(), which also enables the members of a
mixed PMU group and dereferences a NULL fd; call evsel__tool_pmu_enable()
instead. Reported by Sashiko review.
v2 -> v3: Also require evsel->supported, as reading a tool event that never
opened dereferences a NULL core.fd, and correct the explanation of why the
members of a mixed PMU group have no descriptor: get_group_fd() forwards the
leader's descriptor to sys_perf_event_open(), which fails with EINVAL for a
userspace PMU leader. Reported by Sashiko review.
Signed-off-by: TAKANO Mitsuhiro <takano32@gmail.com>
---
tools/perf/builtin-stat.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index c50cf230f16e..334b875d6a2f 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -510,6 +510,19 @@ static int enable_counters(void)
if (!target__enable_on_exec(&target)) {
if (!all_counters_use_bpf)
evlist__enable(evsel_list);
+ } else {
+ /*
+ * Tool events are emulated in perf, so enable_on_exec above
+ * does not start them. Start them here rather than through
+ * evsel__enable(), which also walks the members of a mixed
+ * PMU group; those are not opened here and their core.fd can
+ * be NULL.
+ */
+ evlist__for_each_entry(evsel_list, evsel) {
+ if (evsel__is_tool(evsel) && evsel->supported &&
+ !evsel__tool_pmu_enable(evsel))
+ evsel->disabled = false;
+ }
}
return 0;
}
base-commit: f47d223627f80cb7a1eb14c585fe6cb35de5e984
--
2.53.0
next prev parent reply other threads:[~2026-10-23 10:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 2:49 [PATCH] perf stat: Start tool events when enable_on_exec is used TAKANO Mitsuhiro
2026-10-22 3:14 ` sashiko-bot
2026-10-23 8:55 ` [PATCH v2] " TAKANO Mitsuhiro
2026-10-23 9:22 ` sashiko-bot
2026-10-23 10:12 ` TAKANO Mitsuhiro [this message]
2026-10-23 10:23 ` [PATCH v3] " sashiko-bot
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=20261023101256.1752713-1-takano32@gmail.com \
--to=takano32@gmail.com \
--cc=acme@kernel.org \
--cc=irogers@google.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=namhyung@kernel.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 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.