kernel/tools/perf, branch linux-6.13.y

perf bpf-filter: Fix a parsing error with comma

2025-04-10T12:41:50Z

[ Upstream commit 35d13f841a3d8159ef20d5e32a9ed3faa27875bc ] The previous change to support cgroup filters introduced a bug that pathname can include commas. It confused the lexer to treat an item and the trailing comma as a single token. And it resulted in a parse error: $ sudo perf record -e cycles:P --filter 'period > 0, ip > 64' -- true perf_bpf_filter: Error: Unexpected item: 0, perf_bpf_filter: syntax error, unexpected BFT_ERROR, expecting BFT_NUM Usage: perf record [] [] or: perf record [] -- [] --filter event filter It should get "0" and "," separately. An easiest fix would be to remove "," from the possible pathname characters. As it's for cgroup names, probably ok to assume it won't have commas in the pathname. I found that the existing BPF filtering test didn't have any complex filter condition with commas. Let's update the group filter test which is supposed to test filter combinations like this. Link: https://lore.kernel.org/r/20250307220922.434319-1-namhyung@kernel.org Fixes: 91e88437d5156b20 ("perf bpf-filter: Support filtering on cgroups") Reported-by: Sally Shi Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin

perf tools: annotate asm_pure_loop.S

2025-04-10T12:41:50Z

[ Upstream commit 9a352a90e88a041f4b26d359493e12a7f5ae1a6a ] Annotate so it is built with non-executable stack. Fixes: 8b97519711c3 ("perf test: Add asm pureloop test tool") Signed-off-by: Marcus Meissner Reviewed-by: Leo Yan Link: https://lore.kernel.org/r/20250323085410.23751-1-meissner@suse.de Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin

perf tools: Fix is_compat_mode build break in ppc64

2025-04-10T12:41:50Z

[ Upstream commit 7e442be7015af524d2b5fb84f0ff04a44501542b ] Commit 54f9aa1092457 ("tools/perf/powerpc/util: Add support to handle compatible mode PVR for perf json events") introduced to select proper JSON events in case of compat mode using auxiliary vector. But this caused a compilation error in ppc64 Big Endian. arch/powerpc/util/header.c: In function 'is_compat_mode': arch/powerpc/util/header.c:20:21: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] 20 | if (!strcmp((char *)platform, (char *)base_platform)) | ^ arch/powerpc/util/header.c:20:39: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] 20 | if (!strcmp((char *)platform, (char *)base_platform)) | Commit saved the getauxval(AT_BASE_PLATFORM) and getauxval(AT_PLATFORM) return values in u64 which causes the compilation error. Patch fixes this issue by changing u64 to "unsigned long". Fixes: 54f9aa1092457 ("tools/perf/powerpc/util: Add support to handle compatible mode PVR for perf json events") Signed-off-by: Likhitha Korrapati Reviewed-by: Athira Rajeev Link: https://lore.kernel.org/r/20250321100726.699956-1-likhitha@linux.ibm.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin

perf vendor events arm64 AmpereOneX: Fix frontend_bound calculation

2025-04-10T12:41:50Z

[ Upstream commit 182f12f3193341c3400ae719a34c00a8a1204cff ] frontend_bound metrics was miscalculated due to different scaling in a couple of metrics it depends on. Change the scaling to match with AmpereOne. Fixes: 16438b652b46 ("perf vendor events arm64 AmpereOneX: Add core PMU events and metrics") Signed-off-by: Ilkka Koskinen Reviewed-by: James Clark Link: https://lore.kernel.org/r/20250313201559.11332-3-ilkka@os.amperecomputing.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin

perf: intel-tpebs: Fix incorrect usage of zfree()

2025-04-10T12:41:49Z

[ Upstream commit 6d2dcd635204c023eb5328ad7d38b198a5558c9b ] zfree() requires an address otherwise it frees what's in name, rather than name itself. Pass the address of name to fix it. This was the only incorrect occurrence in Perf found using a search. Fixes: 8db5cabcf1b6 ("perf stat: Fork and launch 'perf record' when 'perf stat' needs to get retire latency value for a metric.") Signed-off-by: James Clark Link: https://lore.kernel.org/r/20250319101614.190922-1-james.clark@linaro.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin

perf dso: fix dso__is_kallsyms() check

2025-04-10T12:41:49Z

[ Upstream commit ebf0b332732dcc64239119e554faa946562b0b93 ] Kernel modules for which we cannot find a file on-disk will have a dso->long_name that looks like "[module_name]". Prior to the commit listed in the fixes, the dso->kernel field would be zero (for user space), so dso__is_kallsyms() would return false. After the commit, kernel module DSOs are correctly labeled, but the result is that dso__is_kallsyms() erroneously returns true for those modules without a filesystem path. Later, build_id_cache__add() consults this value of is_kallsyms, and when true, it copies /proc/kallsyms into the cache. Users with many kernel modules without a filesystem path (e.g. ksplice or possibly kernel live patch modules) have reported excessive disk space usage in the build ID cache directory due to this behavior. To reproduce the issue, it's enough to build a trivial out-of-tree hello world kernel module, load it using insmod, and then use: perf record -ag -- sleep 1 In the build ID directory, there will be a directory for your module name containing a kallsyms file. Fix this up by changing dso__is_kallsyms() to consult the dso_binary_type enumeration, which is also symmetric to the above checks for dso__is_vmlinux() and dso__is_kcore(). With this change, kallsyms is not cached in the build-id cache for out-of-tree modules. Fixes: 02213cec64bbe ("perf maps: Mark module DSOs with kernel type") Signed-off-by: Stephen Brennan Link: https://lore.kernel.org/r/20250318230012.2038790-1-stephen.s.brennan@oracle.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin

perf python: Check if there is space to copy all the event

2025-04-10T12:41:49Z

[ Upstream commit 89aaeaf84231157288035b366cb6300c1c6cac64 ] The pyrf_event__new() method copies the event obtained from the perf ring buffer to a structure that will then be turned into a python object for further consumption, so it copies perf_event.header.size bytes to its 'event' member: $ pahole -C pyrf_event /tmp/build/perf-tools-next/python/perf.cpython-312-x86_64-linux-gnu.so struct pyrf_event { PyObject ob_base; /* 0 16 */ struct evsel * evsel; /* 16 8 */ struct perf_sample sample; /* 24 312 */ /* XXX last struct has 7 bytes of padding, 2 holes */ /* --- cacheline 5 boundary (320 bytes) was 16 bytes ago --- */ union perf_event event; /* 336 4168 */ /* size: 4504, cachelines: 71, members: 4 */ /* member types with holes: 1, total: 2 */ /* paddings: 1, sum paddings: 7 */ /* last cacheline: 24 bytes */ }; $ It was doing so without checking if the event just obtained has more than that space, fix it. This isn't a proper, final solution, as we need to support larger events, but for the time being we at least bounds check and document it. Fixes: 877108e42b1b9ba6 ("perf tools: Initial python binding") Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250312203141.285263-7-acme@kernel.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin

perf python: Don't keep a raw_data pointer to consumed ring buffer space

2025-04-10T12:41:49Z

[ Upstream commit f3fed3ae34d606819d87a63d970cc3092a5be7ab ] When processing tracepoints the perf python binding was parsing the event before calling perf_mmap__consume(&md->core) in pyrf_evlist__read_on_cpu(). But part of this event parsing was to set the perf_sample->raw_data pointer to the payload of the event, which then could be overwritten by other event before tracepoint fields were asked for via event.prev_comm in a python program, for instance. This also happened with other fields, but strings were were problems were surfacing, as there is UTF-8 validation for the potentially garbled data. This ended up showing up as (with some added debugging messages): ( field 'prev_comm' ret=0x7f7c31f65110, raw_size=68 ) ( field 'prev_pid' ret=0x7f7c23b1bed0, raw_size=68 ) ( field 'prev_prio' ret=0x7f7c239c0030, raw_size=68 ) ( field 'prev_state' ret=0x7f7c239c0250, raw_size=68 ) time 14771421785867 prev_comm= prev_pid=1919907691 prev_prio=796026219 prev_state=0x303a32313175 ==> ( XXX '��' len=16, raw_size=68) ( field 'next_comm' ret=(nil), raw_size=68 ) Traceback (most recent call last): File "/home/acme/git/perf-tools-next/tools/perf/python/tracepoint.py", line 51, in main() File "/home/acme/git/perf-tools-next/tools/perf/python/tracepoint.py", line 46, in main event.next_comm, ^^^^^^^^^^^^^^^ AttributeError: 'perf.sample_event' object has no attribute 'next_comm' When event.next_comm was asked for, the PyUnicode_FromString() python API would fail and that tracepoint field wouldn't be available, stopping the tools/perf/python/tracepoint.py test tool. But, since we already do a copy of the whole event in pyrf_event__new, just use it and while at it remove what was done in in e8968e654191390a ("perf python: Fix pyrf_evlist__read_on_cpu event consuming") because we don't really need to wait for parsing the sample before declaring the event as consumed. This copy is questionable as is now, as it limits the maximum event + sample_type and tracepoint payload to sizeof(union perf_event), this all has been "working" because 'struct perf_event_mmap2', the largest entry in 'union perf_event' is: $ pahole -C perf_event ~/bin/perf | grep mmap2 struct perf_record_mmap2 mmap2; /* 0 4168 */ $ Fixes: bae57e3825a3dded ("perf python: Add support to resolve tracepoint fields") Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250312203141.285263-6-acme@kernel.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin

perf python: Decrement the refcount of just created event on failure

2025-04-10T12:41:49Z

[ Upstream commit 3de5a2bf5b4847f7a59a184568f969f8fe05d57f ] To avoid a leak if we have the python object but then something happens and we need to return the operation, decrement the offset of the newly created object. Fixes: 377f698db12150a1 ("perf python: Add struct evsel into struct pyrf_event") Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250312203141.285263-5-acme@kernel.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin

perf python: Fixup description of sample.id event member

2025-04-10T12:41:49Z

[ Upstream commit 1376c195e8ad327bb9f2d32e0acc5ac39e7cb30a ] Some old cut'n'paste error, its "ip", so the description should be "event ip", not "event type". Fixes: 877108e42b1b9ba6 ("perf tools: Initial python binding") Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250312203141.285263-2-acme@kernel.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin