<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/tools/perf, branch linux-6.14.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.14.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.14.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2025-05-22T12:31:58Z</updated>
<entry>
<title>perf tools: Fix build error for LoongArch</title>
<updated>2025-05-22T12:31:58Z</updated>
<author>
<name>Tiezhu Yang</name>
<email>yangtiezhu@loongson.cn</email>
</author>
<published>2025-05-20T06:30:09Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f3bbd4287414b532473d3771e145573e9d7512e6'/>
<id>urn:sha1:f3bbd4287414b532473d3771e145573e9d7512e6</id>
<content type='text'>
There exists the following error when building perf tools on LoongArch:

  CC      util/syscalltbl.o
In file included from util/syscalltbl.c:16:
tools/perf/arch/loongarch/include/syscall_table.h:2:10: fatal error: asm/syscall_table_64.h: No such file or directory
    2 | #include &lt;asm/syscall_table_64.h&gt;
      |          ^~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

This is because the generated syscall header is syscalls_64.h rather
than syscall_table_64.h. The above problem was introduced from v6.14,
then the header syscall_table.h has been removed from mainline tree
in commit af472d3c4454 ("perf syscalltbl: Remove syscall_table.h"),
just fix it only for the linux-6.14.y branch of stable tree.

By the way, no need to fix the mainline tree and there is no upstream
git id for this patch.

How to reproduce:

  git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
  cd linux &amp;&amp; git checkout origin/linux-6.14.y
  make JOBS=1 -C tools/perf

Fixes: fa70857a27e5 ("perf tools loongarch: Use syscall table")
Signed-off-by: Tiezhu Yang &lt;yangtiezhu@loongson.cn&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>perf tools: Remove evsel__handle_error_quirks()</title>
<updated>2025-04-25T08:50:51Z</updated>
<author>
<name>Namhyung Kim</name>
<email>namhyung@kernel.org</email>
</author>
<published>2025-04-10T01:02:52Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=716fb384294dc536d3f55bd381ce316b9f743313'/>
<id>urn:sha1:716fb384294dc536d3f55bd381ce316b9f743313</id>
<content type='text'>
[ Upstream commit 2b70702917337a8d6d07f03eed961e0119091647 ]

The evsel__handle_error_quirks() is to fixup invalid event attributes on
some architecture based on the error code.  Currently it's only used for
AMD to disable precise_ip not to use IBS which has more restrictions.

But the commit c33aea446bf555ab changed call evsel__precise_ip_fallback
for any errors so there's no difference with the above function.  To
make matter worse, it caused a problem with branch stack on Zen3.

The IBS doesn't support branch stack so it should use a regular core
PMU event.  The default event is set precise_max and it starts with 3.
And evsel__precise_ip_fallback() tries with it and reduces the level one
by one.  At last it tries with 0 but it also failed on Zen3 since the
branch stack is not supported for the cycles event.

At this point, evsel__precise_ip_fallback() restores the original
precise_ip value (3) in the hope that it can succeed with other modifier
(like exclude_kernel).  Then evsel__handle_error_quirks() see it has
precise_ip != 0 and make it retry with 0.  This created an infinite
loop.

Before:

  $ perf record -b -vv |&amp; grep removing
  removing precise_ip on AMD
  removing precise_ip on AMD
  removing precise_ip on AMD
  removing precise_ip on AMD
  removing precise_ip on AMD
  removing precise_ip on AMD
  removing precise_ip on AMD
  removing precise_ip on AMD
  removing precise_ip on AMD
  removing precise_ip on AMD
  removing precise_ip on AMD
  removing precise_ip on AMD
  ...

After:

  $ perf record -b true
  Error:
  Failure to open event 'cycles:P' on PMU 'cpu' which will be removed.
  Invalid event (cycles:P) in per-thread mode, enable system wide with '-a'.
  Error:
  Failure to open any events for recording.

Fixes: c33aea446bf555ab ("perf tools: Fix precise_ip fallback logic")
Tested-by: Chun-Tse Shao &lt;ctshao@google.com&gt;
Cc: Ravi Bangoria &lt;ravi.bangoria@amd.com&gt;
Link: https://lore.kernel.org/r/20250410010252.402221-1-namhyung@kernel.org
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf pmu: Rename name matching for no suffix or wildcard variants</title>
<updated>2025-04-10T12:44:48Z</updated>
<author>
<name>Ian Rogers</name>
<email>irogers@google.com</email>
</author>
<published>2025-02-01T07:43:18Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=198f2b471c4252b0d1abc5490620e526d080cdf2'/>
<id>urn:sha1:198f2b471c4252b0d1abc5490620e526d080cdf2</id>
<content type='text'>
commit 63e287131cf0c59b026053d6d63fe271604ffa7e upstream.

Wildcard PMU naming will match a name like pmu_1 to a PMU name like
pmu_10 but not to a PMU name like pmu_2 as the suffix forms part of
the match. No suffix matching will match pmu_10 to either pmu_1 or
pmu_2. Add or rename matching functions on PMU to make it clearer what
kind of matching is being performed.

Signed-off-by: Ian Rogers &lt;irogers@google.com&gt;
Reviewed-by: Kan Liang &lt;kan.liang@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20250201074320.746259-4-irogers@google.com
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>perf bpf-filter: Fix a parsing error with comma</title>
<updated>2025-04-10T12:44:34Z</updated>
<author>
<name>Namhyung Kim</name>
<email>namhyung@kernel.org</email>
</author>
<published>2025-03-07T22:09:21Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=4dc1f33bfac82af099731fc5b5243340bae2276f'/>
<id>urn:sha1:4dc1f33bfac82af099731fc5b5243340bae2276f</id>
<content type='text'>
[ 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 &gt; 0, ip &gt; 64' -- true
  perf_bpf_filter: Error: Unexpected item: 0,
  perf_bpf_filter: syntax error, unexpected BFT_ERROR, expecting BFT_NUM

   Usage: perf record [&lt;options&gt;] [&lt;command&gt;]
      or: perf record [&lt;options&gt;] -- &lt;command&gt; [&lt;options&gt;]

          --filter &lt;filter&gt;
                            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 &lt;sshii@google.com&gt;
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf tools: annotate asm_pure_loop.S</title>
<updated>2025-04-10T12:44:34Z</updated>
<author>
<name>Marcus Meissner</name>
<email>meissner@suse.de</email>
</author>
<published>2025-03-23T08:53:45Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2e8251afe2af2d1582a22f27440761d480f14fec'/>
<id>urn:sha1:2e8251afe2af2d1582a22f27440761d480f14fec</id>
<content type='text'>
[ 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 &lt;meissner@suse.de&gt;
Reviewed-by: Leo Yan &lt;leo.yan@arm.com&gt;
Link: https://lore.kernel.org/r/20250323085410.23751-1-meissner@suse.de
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf tools: Fix is_compat_mode build break in ppc64</title>
<updated>2025-04-10T12:44:34Z</updated>
<author>
<name>Likhitha Korrapati</name>
<email>likhitha@linux.ibm.com</email>
</author>
<published>2025-03-21T10:07:26Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f1e30175f3581fa6b66ceb8cab33c9977b3e1600'/>
<id>urn:sha1:f1e30175f3581fa6b66ceb8cab33c9977b3e1600</id>
<content type='text'>
[ 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 &lt;likhitha@linux.ibm.com&gt;
Reviewed-by: Athira Rajeev &lt;atrajeev@linux.ibm.com&gt;
Link: https://lore.kernel.org/r/20250321100726.699956-1-likhitha@linux.ibm.com
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf vendor events arm64 AmpereOneX: Fix frontend_bound calculation</title>
<updated>2025-04-10T12:44:34Z</updated>
<author>
<name>Ilkka Koskinen</name>
<email>ilkka@os.amperecomputing.com</email>
</author>
<published>2025-03-13T20:15:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c4a645c4654513b107b6e274dc1049f929aa3bf4'/>
<id>urn:sha1:c4a645c4654513b107b6e274dc1049f929aa3bf4</id>
<content type='text'>
[ 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 &lt;ilkka@os.amperecomputing.com&gt;
Reviewed-by: James Clark &lt;james.clark@linaro.org&gt;
Link: https://lore.kernel.org/r/20250313201559.11332-3-ilkka@os.amperecomputing.com
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf pmu: Handle memory failure in tool_pmu__new()</title>
<updated>2025-04-10T12:44:34Z</updated>
<author>
<name>Thomas Richter</name>
<email>tmricht@linux.ibm.com</email>
</author>
<published>2025-03-19T12:28:20Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d70e3e8a38928c3dc0aa605ba8731c3a0071c871'/>
<id>urn:sha1:d70e3e8a38928c3dc0aa605ba8731c3a0071c871</id>
<content type='text'>
[ Upstream commit 431db90a7303cb394c5a881b4479946f64052727 ]

On linux-next
commit 72c6f57a4193 ("perf pmu: Dynamically allocate tool PMU")
allocated PMU named "tool" dynamicly. However that allocation
can fail and a NULL pointer is returned. That case is currently
not handled and would result in an invalid address reference.
Add a check for NULL pointer.

Fixes: 72c6f57a4193 ("perf pmu: Dynamically allocate tool PMU")
Signed-off-by: Thomas Richter &lt;tmricht@linux.ibm.com&gt;
Reviewed-by: James Clark &lt;james.clark@linaro.org&gt;
Link: https://lore.kernel.org/r/20250319122820.2898333-1-tmricht@linux.ibm.com
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf: intel-tpebs: Fix incorrect usage of zfree()</title>
<updated>2025-04-10T12:44:34Z</updated>
<author>
<name>James Clark</name>
<email>james.clark@linaro.org</email>
</author>
<published>2025-03-19T10:16:10Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3b77fa84b2f2cca1aafc11ca373a6c7009b11f8d'/>
<id>urn:sha1:3b77fa84b2f2cca1aafc11ca373a6c7009b11f8d</id>
<content type='text'>
[ 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 &lt;james.clark@linaro.org&gt;
Link: https://lore.kernel.org/r/20250319101614.190922-1-james.clark@linaro.org
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf dso: fix dso__is_kallsyms() check</title>
<updated>2025-04-10T12:44:33Z</updated>
<author>
<name>Stephen Brennan</name>
<email>stephen.s.brennan@oracle.com</email>
</author>
<published>2025-03-18T23:00:11Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=408065a4db6e0a9daf24af1118fa335db42586a6'/>
<id>urn:sha1:408065a4db6e0a9daf24af1118fa335db42586a6</id>
<content type='text'>
[ Upstream commit ebf0b332732dcc64239119e554faa946562b0b93 ]

Kernel modules for which we cannot find a file on-disk will have a
dso-&gt;long_name that looks like "[module_name]". Prior to the commit
listed in the fixes, the dso-&gt;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 &lt;stephen.s.brennan@oracle.com&gt;
Link: https://lore.kernel.org/r/20250318230012.2038790-1-stephen.s.brennan@oracle.com
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
