Re: [PATCH 6.12 375/666] perf tool_pmu: Factor tool events into their own PMU
Namhyung Kim <[email protected]>
| Newsgroups | dev.linux.lists.regressions,dev.linux.lists.patches,org.kernel.vger.stable |
|---|---|
| Message-ID | <[email protected]> |
Hello, On Tue, May 26, 2026 at 07:21:33PM -0400, Tyler Stachecki wrote: > On Sun, May 24, 2026 at 04:46:48PM +0200, Salvatore Bonaccorso wrote: > > hi Greg, > > On Wed, May 20, 2026 at 06:19:46PM +0200, Greg Kroah-Hartman wrote: > > > 6.12-stable review patch. If anyone has any objections, please let me know. > > > > > > ------------------ > > > > > > From: Ian Rogers <[email protected]> > > > > > > [ Upstream commit 240505b2d0adcdc8fd018117e88dc27b09734735 ] > > > > > > Rather than treat tool events as a special kind of event, create a > > > tool only PMU where the events/aliases match the existing > > > duration_time, user_time and system_time events. Remove special > > > parsing and printing support for the tool events, but add function > > > calls for when PMU functions are called on a tool_pmu. > > > > > > Move the tool PMU code in evsel into tool_pmu.c to better encapsulate > > > the tool event behavior in that file. > > > > While building now a complete set of packages for Debian for 6.12.91 > > where perf tools are included as well, I noticed that now the builds > > fails. In fact in v6.12.91 > > > > $ cd tools > > $ LC_ALL=C.UTF-8 ARCH=x86 make perf > > > > fails with: > > > > [...] > > CC util/stat.o > > util/tool_pmu.c: In function ‘tool_pmu__config_term’: > > util/tool_pmu.c:62:49: error: implicit declaration of function ‘parse_events__term_type_str’; did you mean ‘parse_events_term__str’? [-Wimplicit-function-declaration] > > 62 | parse_events__term_type_str(term->type_term), > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ > > | parse_events_term__str > > util/tool_pmu.c:61:79: error: format ‘%s’ expects argument of type ‘char *’, but argument 3 has type ‘int’ [-Werror=format=] > > 61 | "unexpected tool event term (%s) %s", > > | ~^ > > | | > > | char * > > | %d > > 62 | parse_events__term_type_str(term->type_term), > > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > | | > > | int > > cc1: all warnings being treated as errors > > CC util/stat-shadow.o > > LD util/hisi-ptt-decoder/perf-util-in.o > > CC util/stat-display.o > > make[5]: *** [/home/build/linux-stable-rc/tools/build/Makefile.build:105: util/tool_pmu.o] Error 1 > > make[5]: *** Waiting for unfinished jobs.... > > CC util/perf_api_probe.o > > LD util/perf-regs-arch/perf-util-in.o > > util/cgroup.c: In function ‘evlist__expand_cgroup’: > > util/cgroup.c:498:32: error: ‘struct evsel’ has no member named ‘first_wildcard_match’ > > 498 | if (pos->first_wildcard_match) > > | ^~ > > util/cgroup.c:499:38: error: ‘struct evsel’ has no member named ‘first_wildcard_match’ > > 499 | evsel->first_wildcard_match = pos->first_wildcard_match->priv; > > | ^~ > > util/cgroup.c:499:66: error: ‘struct evsel’ has no member named ‘first_wildcard_match’ > > 499 | evsel->first_wildcard_match = pos->first_wildcard_match->priv; > > | ^~ > > make[5]: *** [/home/build/linux-stable-rc/tools/build/Makefile.build:105: util/cgroup.o] Error 1 > > LD util/arm-spe-decoder/perf-util-in.o > > LD ui/browsers/perf-ui-in.o > > LD tests/workloads/perf-test-in.o > > LD ui/perf-ui-in.o > > LD perf-ui-in.o > > AR libperf-ui.a > > LD tests/perf-test-in.o > > LD perf-test-in.o > > AR libperf-test.a > > LD util/scripting-engines/perf-util-in.o > > LD util/intel-pt-decoder/perf-util-in.o > > LD perf-in.o > > make[4]: *** [/home/build/linux-stable-rc/tools/build/Makefile.build:162: util] Error 2 > > make[3]: *** [Makefile.perf:789: perf-util-in.o] Error 2 > > make[3]: *** Waiting for unfinished jobs.... > > CC pmu-events/pmu-events.o > > LD pmu-events/pmu-events-in.o > > make[2]: *** [Makefile.perf:292: sub-make] Error 2 > > make[1]: *** [Makefile:76: all] Error 2 > > make: *** [Makefile:93: perf] Error 2 > > > > Regards, > > Salvatore > > Second this - moreover, because of the other commits introduced in tools/perf > as of 6.12.91, it's not possible to revert just this one commit without other > conflicts. I don't think it's meant to be in the stable tree. Maybe need to drop this and later patches depend on it. Thanks, Namhyung