<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/tools/lib, branch linux-6.16.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>perf subcmd: avoid crash in exclude_cmds when excludes is empty</title>
<updated>2025-10-12T11:01:02+00:00</updated>
<author>
<name>hupu</name>
<email>hupu.gm@gmail.com</email>
</author>
<published>2025-09-10T08:16:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=86b306f3a7faf5d25aa40d799627968c7831c32f'/>
<id>86b306f3a7faf5d25aa40d799627968c7831c32f</id>
<content type='text'>
[ Upstream commit a5edf3550f4260504b7e0ab3d40d13ffe924b773 ]

When cross-compiling the perf tool for ARM64, `perf help` may crash
with the following assertion failure:

  help.c:122: exclude_cmds: Assertion `cmds-&gt;names[ci] == NULL' failed.

This happens when the perf binary is not named exactly "perf" or when
multiple "perf-*" binaries exist in the same directory. In such cases,
the `excludes` command list can be empty, which leads to the final
assertion in exclude_cmds() being triggered.

Add a simple guard at the beginning of exclude_cmds() to return early
if excludes-&gt;cnt is zero, preventing the crash.

Signed-off-by: hupu &lt;hupu.gm@gmail.com&gt;
Reported-by: Guilherme Amadio &lt;amadio@gentoo.org&gt;
Reviewed-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Link: https://lore.kernel.org/r/20250909094953.106706-1-amadio@gentoo.org
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit a5edf3550f4260504b7e0ab3d40d13ffe924b773 ]

When cross-compiling the perf tool for ARM64, `perf help` may crash
with the following assertion failure:

  help.c:122: exclude_cmds: Assertion `cmds-&gt;names[ci] == NULL' failed.

This happens when the perf binary is not named exactly "perf" or when
multiple "perf-*" binaries exist in the same directory. In such cases,
the `excludes` command list can be empty, which leads to the final
assertion in exclude_cmds() being triggered.

Add a simple guard at the beginning of exclude_cmds() to return early
if excludes-&gt;cnt is zero, preventing the crash.

Signed-off-by: hupu &lt;hupu.gm@gmail.com&gt;
Reported-by: Guilherme Amadio &lt;amadio@gentoo.org&gt;
Reviewed-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Link: https://lore.kernel.org/r/20250909094953.106706-1-amadio@gentoo.org
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>libbpf: Fix warning in calloc() usage</title>
<updated>2025-08-20T16:41:07+00:00</updated>
<author>
<name>Matteo Croce</name>
<email>teknoraver@meta.com</email>
</author>
<published>2025-07-17T20:03:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=68c4dd208875aeea90f48b40f2cf841de6f94c2b'/>
<id>68c4dd208875aeea90f48b40f2cf841de6f94c2b</id>
<content type='text'>
[ Upstream commit 0ee30d937c147fc14c4b49535181d437cd2fde7a ]

When compiling libbpf with some compilers, this warning is triggered:

libbpf.c: In function ‘bpf_object__gen_loader’:
libbpf.c:9209:28: error: ‘calloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
 9209 |         gen = calloc(sizeof(*gen), 1);
      |                            ^
libbpf.c:9209:28: note: earlier argument should specify number of elements, later size of each element

Fix this by inverting the calloc() arguments.

Signed-off-by: Matteo Croce &lt;teknoraver@meta.com&gt;
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Acked-by: Yonghong Song &lt;yonghong.song@linux.dev&gt;
Link: https://lore.kernel.org/bpf/20250717200337.49168-1-technoboy85@gmail.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 0ee30d937c147fc14c4b49535181d437cd2fde7a ]

When compiling libbpf with some compilers, this warning is triggered:

libbpf.c: In function ‘bpf_object__gen_loader’:
libbpf.c:9209:28: error: ‘calloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
 9209 |         gen = calloc(sizeof(*gen), 1);
      |                            ^
libbpf.c:9209:28: note: earlier argument should specify number of elements, later size of each element

Fix this by inverting the calloc() arguments.

Signed-off-by: Matteo Croce &lt;teknoraver@meta.com&gt;
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Acked-by: Yonghong Song &lt;yonghong.song@linux.dev&gt;
Link: https://lore.kernel.org/bpf/20250717200337.49168-1-technoboy85@gmail.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>libbpf: Verify that arena map exists when adding arena relocations</title>
<updated>2025-08-20T16:41:06+00:00</updated>
<author>
<name>Eduard Zingerman</name>
<email>eddyz87@gmail.com</email>
</author>
<published>2025-07-18T22:20:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a114913c34d9059b63f4632a3b1efd158871e487'/>
<id>a114913c34d9059b63f4632a3b1efd158871e487</id>
<content type='text'>
[ Upstream commit 42be23e8f2dcb100cb9944b2b54b6bf41aff943d ]

Fuzzer reported a memory access error in bpf_program__record_reloc()
that happens when:
- ".addr_space.1" section exists
- there is a relocation referencing this section
- there are no arena maps defined in BTF.

Sanity checks for maps existence are already present in
bpf_program__record_reloc(), hence this commit adds another one.

[1] https://github.com/libbpf/libbpf/actions/runs/16375110681/job/46272998064

Signed-off-by: Eduard Zingerman &lt;eddyz87@gmail.com&gt;
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20250718222059.281526-1-eddyz87@gmail.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 42be23e8f2dcb100cb9944b2b54b6bf41aff943d ]

Fuzzer reported a memory access error in bpf_program__record_reloc()
that happens when:
- ".addr_space.1" section exists
- there is a relocation referencing this section
- there are no arena maps defined in BTF.

Sanity checks for maps existence are already present in
bpf_program__record_reloc(), hence this commit adds another one.

[1] https://github.com/libbpf/libbpf/actions/runs/16375110681/job/46272998064

Signed-off-by: Eduard Zingerman &lt;eddyz87@gmail.com&gt;
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20250718222059.281526-1-eddyz87@gmail.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tools subcmd: Tighten the filename size in check_if_command_finished</title>
<updated>2025-08-15T14:39:11+00:00</updated>
<author>
<name>Ian Rogers</name>
<email>irogers@google.com</email>
</author>
<published>2025-07-17T15:08:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f82782902270eca855a3c38a455f34551eaeb420'/>
<id>f82782902270eca855a3c38a455f34551eaeb420</id>
<content type='text'>
[ Upstream commit 478272d1cdd9959a6d638e9d81f70642f04290c9 ]

FILENAME_MAX is often PATH_MAX (4kb), far more than needed for the
/proc path. Make the buffer size sufficient for the maximum integer
plus "/proc/" and "/status" with a '\0' terminator.

Fixes: 5ce42b5de461 ("tools subcmd: Add non-waitpid check_if_command_finished()")
Signed-off-by: Ian Rogers &lt;irogers@google.com&gt;
Link: https://lore.kernel.org/r/20250717150855.1032526-1-irogers@google.com
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 478272d1cdd9959a6d638e9d81f70642f04290c9 ]

FILENAME_MAX is often PATH_MAX (4kb), far more than needed for the
/proc path. Make the buffer size sufficient for the maximum integer
plus "/proc/" and "/status" with a '\0' terminator.

Fixes: 5ce42b5de461 ("tools subcmd: Add non-waitpid check_if_command_finished()")
Signed-off-by: Ian Rogers &lt;irogers@google.com&gt;
Link: https://lore.kernel.org/r/20250717150855.1032526-1-irogers@google.com
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>perf tools: Fix use-after-free in help_unknown_cmd()</title>
<updated>2025-08-15T14:39:03+00:00</updated>
<author>
<name>Namhyung Kim</name>
<email>namhyung@kernel.org</email>
</author>
<published>2025-07-01T20:10:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9401d1771dad99bfc795dd2ae0c292343fd1f78d'/>
<id>9401d1771dad99bfc795dd2ae0c292343fd1f78d</id>
<content type='text'>
[ Upstream commit 1fdf938168c4d26fa279d4f204768690d1f9c4ae ]

Currently perf aborts when it finds an invalid command.  I guess it
depends on the environment as I have some custom commands in the path.

  $ perf bad-command
  perf: 'bad-command' is not a perf-command. See 'perf --help'.
  Aborted (core dumped)

It's because the exclude_cmds() in libsubcmd has a use-after-free when
it removes some entries.  After copying one to another entry, it keeps
the pointer in the both position.  And the next copy operation will free
the later one but it's the same entry in the previous one.

For example, let's say cmds = { A, B, C, D, E } and excludes = { B, E }.

  ci  cj  ei   cmds-name  excludes
  -----------+--------------------
   0   0   0 |     A         B       :    cmp &lt; 0, ci == cj
   1   1   0 |     B         B       :    cmp == 0
   2   1   1 |     C         E       :    cmp &lt; 0, ci != cj

At this point, it frees cmds-&gt;names[1] and cmds-&gt;names[1] is assigned to
cmds-&gt;names[2].

   3   2   1 |     D         E       :    cmp &lt; 0, ci != cj

Now it frees cmds-&gt;names[2] but it's the same as cmds-&gt;names[1].  So
accessing cmds-&gt;names[1] will be invalid.

This makes the subcmd tests succeed.

  $ perf test subcmd
   69: libsubcmd help tests                                            :
   69.1: Load subcmd names                                             : Ok
   69.2: Uniquify subcmd names                                         : Ok
   69.3: Exclude duplicate subcmd names                                : Ok

Fixes: 4b96679170c6 ("libsubcmd: Avoid SEGV/use-after-free when commands aren't excluded")
Reviewed-by: Ian Rogers &lt;irogers@google.com&gt;
Link: https://lore.kernel.org/r/20250701201027.1171561-3-namhyung@kernel.org
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 1fdf938168c4d26fa279d4f204768690d1f9c4ae ]

Currently perf aborts when it finds an invalid command.  I guess it
depends on the environment as I have some custom commands in the path.

  $ perf bad-command
  perf: 'bad-command' is not a perf-command. See 'perf --help'.
  Aborted (core dumped)

It's because the exclude_cmds() in libsubcmd has a use-after-free when
it removes some entries.  After copying one to another entry, it keeps
the pointer in the both position.  And the next copy operation will free
the later one but it's the same entry in the previous one.

For example, let's say cmds = { A, B, C, D, E } and excludes = { B, E }.

  ci  cj  ei   cmds-name  excludes
  -----------+--------------------
   0   0   0 |     A         B       :    cmp &lt; 0, ci == cj
   1   1   0 |     B         B       :    cmp == 0
   2   1   1 |     C         E       :    cmp &lt; 0, ci != cj

At this point, it frees cmds-&gt;names[1] and cmds-&gt;names[1] is assigned to
cmds-&gt;names[2].

   3   2   1 |     D         E       :    cmp &lt; 0, ci != cj

Now it frees cmds-&gt;names[2] but it's the same as cmds-&gt;names[1].  So
accessing cmds-&gt;names[1] will be invalid.

This makes the subcmd tests succeed.

  $ perf test subcmd
   69: libsubcmd help tests                                            :
   69.1: Load subcmd names                                             : Ok
   69.2: Uniquify subcmd names                                         : Ok
   69.3: Exclude duplicate subcmd names                                : Ok

Fixes: 4b96679170c6 ("libsubcmd: Avoid SEGV/use-after-free when commands aren't excluded")
Reviewed-by: Ian Rogers &lt;irogers@google.com&gt;
Link: https://lore.kernel.org/r/20250701201027.1171561-3-namhyung@kernel.org
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>libbpf: Fix handling of BPF arena relocations</title>
<updated>2025-07-18T02:17:46+00:00</updated>
<author>
<name>Andrii Nakryiko</name>
<email>andrii@kernel.org</email>
</author>
<published>2025-07-18T00:10:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0238c45fbbf8228f52aa4642f0cdc21c570d1dfe'/>
<id>0238c45fbbf8228f52aa4642f0cdc21c570d1dfe</id>
<content type='text'>
Initial __arena global variable support implementation in libbpf
contains a bug: it remembers struct bpf_map pointer for arena, which is
used later on to process relocations. Recording this pointer is
problematic because map pointers are not stable during ELF relocation
collection phase, as an array of struct bpf_map's can be reallocated,
invalidating all the pointers. Libbpf is dealing with similar issues by
using a stable internal map index, though for BPF arena map specifically
this approach wasn't used due to an oversight.

The resulting behavior is non-deterministic issue which depends on exact
layout of ELF object file, number of actual maps, etc. We didn't hit
this until very recently, when this bug started triggering crash in BPF
CI when validating one of sched-ext BPF programs.

The fix is rather straightforward: we just follow an established pattern
of remembering map index (just like obj-&gt;kconfig_map_idx, for example)
instead of `struct bpf_map *`, and resolving index to a pointer at the
point where map information is necessary.

While at it also add debug-level message for arena-related relocation
resolution information, which we already have for all other kinds of
maps.

Fixes: 2e7ba4f8fd1f ("libbpf: Recognize __arena global variables.")
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Tested-by: Eduard Zingerman &lt;eddyz87@gmail.com&gt;
Link: https://lore.kernel.org/r/20250718001009.610955-1-andrii@kernel.org
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Initial __arena global variable support implementation in libbpf
contains a bug: it remembers struct bpf_map pointer for arena, which is
used later on to process relocations. Recording this pointer is
problematic because map pointers are not stable during ELF relocation
collection phase, as an array of struct bpf_map's can be reallocated,
invalidating all the pointers. Libbpf is dealing with similar issues by
using a stable internal map index, though for BPF arena map specifically
this approach wasn't used due to an oversight.

The resulting behavior is non-deterministic issue which depends on exact
layout of ELF object file, number of actual maps, etc. We didn't hit
this until very recently, when this bug started triggering crash in BPF
CI when validating one of sched-ext BPF programs.

The fix is rather straightforward: we just follow an established pattern
of remembering map index (just like obj-&gt;kconfig_map_idx, for example)
instead of `struct bpf_map *`, and resolving index to a pointer at the
point where map information is necessary.

While at it also add debug-level message for arena-related relocation
resolution information, which we already have for all other kinds of
maps.

Fixes: 2e7ba4f8fd1f ("libbpf: Recognize __arena global variables.")
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Tested-by: Eduard Zingerman &lt;eddyz87@gmail.com&gt;
Link: https://lore.kernel.org/r/20250718001009.610955-1-andrii@kernel.org
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>libbpf: Fix possible use-after-free for externs</title>
<updated>2025-06-25T19:28:58+00:00</updated>
<author>
<name>Adin Scannell</name>
<email>amscanne@meta.com</email>
</author>
<published>2025-06-25T05:02:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fa6f092cc0a02d0fcee37e9e8172eda372a03d33'/>
<id>fa6f092cc0a02d0fcee37e9e8172eda372a03d33</id>
<content type='text'>
The `name` field in `obj-&gt;externs` points into the BTF data at initial
open time. However, some functions may invalidate this after opening and
before loading (e.g. `bpf_map__set_value_size`), which results in
pointers into freed memory and undefined behavior.

The simplest solution is to simply `strdup` these strings, similar to
the `essent_name`, and free them at the same time.

In order to test this path, the `global_map_resize` BPF selftest is
modified slightly to ensure the presence of an extern, which causes this
test to fail prior to the fix. Given there isn't an obvious API or error
to test against, I opted to add this to the existing test as an aspect
of the resizing feature rather than duplicate the test.

Fixes: 9d0a23313b1a ("libbpf: Add capability for resizing datasec maps")
Signed-off-by: Adin Scannell &lt;amscanne@meta.com&gt;
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20250625050215.2777374-1-amscanne@meta.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The `name` field in `obj-&gt;externs` points into the BTF data at initial
open time. However, some functions may invalidate this after opening and
before loading (e.g. `bpf_map__set_value_size`), which results in
pointers into freed memory and undefined behavior.

The simplest solution is to simply `strdup` these strings, similar to
the `essent_name`, and free them at the same time.

In order to test this path, the `global_map_resize` BPF selftest is
modified slightly to ensure the presence of an extern, which causes this
test to fail prior to the fix. Given there isn't an obvious API or error
to test against, I opted to add this to the existing test as an aspect
of the resizing feature rather than duplicate the test.

Fixes: 9d0a23313b1a ("libbpf: Add capability for resizing datasec maps")
Signed-off-by: Adin Scannell &lt;amscanne@meta.com&gt;
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20250625050215.2777374-1-amscanne@meta.com
</pre>
</div>
</content>
</entry>
<entry>
<title>libbpf: Fix null pointer dereference in btf_dump__free on allocation failure</title>
<updated>2025-06-23T18:13:40+00:00</updated>
<author>
<name>Yuan Chen</name>
<email>chenyuan@kylinos.cn</email>
</author>
<published>2025-06-18T01:19:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=aa485e8789d56a4573f7c8d000a182b749eaa64d'/>
<id>aa485e8789d56a4573f7c8d000a182b749eaa64d</id>
<content type='text'>
When btf_dump__new() fails to allocate memory for the internal hashmap
(btf_dump-&gt;type_names), it returns an error code. However, the cleanup
function btf_dump__free() does not check if btf_dump-&gt;type_names is NULL
before attempting to free it. This leads to a null pointer dereference
when btf_dump__free() is called on a btf_dump object.

Fixes: 351131b51c7a ("libbpf: add btf_dump API for BTF-to-C conversion")
Signed-off-by: Yuan Chen &lt;chenyuan@kylinos.cn&gt;
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20250618011933.11423-1-chenyuan_fl@163.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When btf_dump__new() fails to allocate memory for the internal hashmap
(btf_dump-&gt;type_names), it returns an error code. However, the cleanup
function btf_dump__free() does not check if btf_dump-&gt;type_names is NULL
before attempting to free it. This leads to a null pointer dereference
when btf_dump__free() is called on a btf_dump object.

Fixes: 351131b51c7a ("libbpf: add btf_dump API for BTF-to-C conversion")
Signed-off-by: Yuan Chen &lt;chenyuan@kylinos.cn&gt;
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20250618011933.11423-1-chenyuan_fl@163.com
</pre>
</div>
</content>
</entry>
<entry>
<title>libbpf: Handle unsupported mmap-based /sys/kernel/btf/vmlinux correctly</title>
<updated>2025-06-06T21:07:07+00:00</updated>
<author>
<name>Andrii Nakryiko</name>
<email>andrii@kernel.org</email>
</author>
<published>2025-06-06T20:21:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=02670deede2288d8e4e3d800477b27c091080fae'/>
<id>02670deede2288d8e4e3d800477b27c091080fae</id>
<content type='text'>
libbpf_err_ptr() helpers are meant to return NULL and set errno, if
there is an error. But btf_parse_raw_mmap() is meant to be used
internally and is expected to return ERR_PTR() values. Because of this
mismatch, when libbpf tries to mmap /sys/kernel/btf/vmlinux, we don't
detect the error correctly with IS_ERR() check, and never fallback to
old non-mmap-based way of loading vmlinux BTF.

Fix this by using proper ERR_PTR() returns internally.

Reported-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Reviewed-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Tested-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Fixes: 3c0421c93ce4 ("libbpf: Use mmap to parse vmlinux BTF from sysfs")
Cc: Lorenz Bauer &lt;lmb@isovalent.com&gt;
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Link: https://lore.kernel.org/r/20250606202134.2738910-1-andrii@kernel.org
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
libbpf_err_ptr() helpers are meant to return NULL and set errno, if
there is an error. But btf_parse_raw_mmap() is meant to be used
internally and is expected to return ERR_PTR() values. Because of this
mismatch, when libbpf tries to mmap /sys/kernel/btf/vmlinux, we don't
detect the error correctly with IS_ERR() check, and never fallback to
old non-mmap-based way of loading vmlinux BTF.

Fix this by using proper ERR_PTR() returns internally.

Reported-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Reviewed-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Tested-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Fixes: 3c0421c93ce4 ("libbpf: Use mmap to parse vmlinux BTF from sysfs")
Cc: Lorenz Bauer &lt;lmb@isovalent.com&gt;
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Link: https://lore.kernel.org/r/20250606202134.2738910-1-andrii@kernel.org
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'perf-tools-for-v6.16-1-2025-06-03' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools</title>
<updated>2025-06-03T22:11:44+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2025-06-03T22:11:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0939bd2fcf337243133b0271335a2838857c319f'/>
<id>0939bd2fcf337243133b0271335a2838857c319f</id>
<content type='text'>
Pull perf tools updates from Arnaldo Carvalho de Melo:
 "perf report/top/annotate TUI:

   - Accept the left arrow key as a Zoom out if done on the first column

   - Show if source code toggle status in title, to help spotting bugs
     with the various disassemblers (capstone, llvm, objdump)

   - Provide feedback on unhandled hotkeys

  Build:

   - Better inform when certain features are not available with warnings
     in the build process and in 'perf version --build-options' or 'perf -vv'

  perf record:

   - Improve the --off-cpu code by synthesizing events for switch-out -&gt;
     switch-in intervals using a BPF program. This can be fine tuned
     using a --off-cpu-thresh knob

  perf report:

   - Add 'tgid' sort key

  perf mem/c2c:

   - Add 'op', 'cache', 'snoop', 'dtlb' output fields

   - Add support for 'ldlat' on AMD IBS (Instruction Based Sampling)

  perf ftrace:

   - Use process/session specific trace settings instead of messing with
     the global ftrace knobs

  perf trace:

   - Implement syscall summary in BPF

   - Support --summary-mode=cgroup

   - Always print return value for syscalls returning a pid

   - The rseq and set_robust_list don't return a pid, just -errno

  perf lock contention:

   - Symbolize zone-&gt;lock using BTF

   - Add -J/--inject-delay option to estimate impact on application
     performance by optimization of kernel locking behavior

  perf stat:

   - Improve hybrid support for the NMI watchdog warning

  Symbol resolution:

   - Handle 'u' and 'l' symbols in /proc/kallsyms, resolving some Rust
     symbols

   - Improve Rust demangler

  Hardware tracing:

  Intel PT:

   - Fix PEBS-via-PT data_src

   - Do not default to recording all switch events

   - Fix pattern matching with python3 on the SQL viewer script

  arm64:

   - Fixups for the hip08 hha PMU

  Vendor events:

   - Update Intel events/metrics files for alderlake, alderlaken,
     arrowlake, bonnell, broadwell, broadwellde, broadwellx,
     cascadelakex, clearwaterforest, elkhartlake, emeraldrapids,
     grandridge, graniterapids, haswell, haswellx, icelake, icelakex,
     ivybridge, ivytown, jaketown, lunarlake, meteorlake, nehalemep,
     nehalemex, rocketlake, sandybridge, sapphirerapids, sierraforest,
     skylake, skylakex, snowridgex, tigerlake, westmereep-dp,
     westmereep-sp, westmereep-sx

  python support:

   - Add support for event counts in the python binding, add a
     counting.py example

  perf list:

   - Display the PMU name associated with a perf metric in JSON

  perf test:

   - Hybrid improvements for metric value validation test

   - Fix LBR test by ignoring idle task

   - Add AMD IBS sw filter ana d'ldlat' tests

   - Add 'perf trace --summary-mode=cgroup' test

   - Add tests for the various language symbol demanglers

  Miscellaneous:

   - Allow specifying the cpu an event will be tied using '-e
     event/cpu=N/'

   - Sync various headers with the kernel sources

   - Add annotations to use clang's -Wthread-safety and fix some
     problems it detected

   - Make dump_stack() use perf's symbol resolution to provide better
     backtraces

   - Intel TPEBS support cleanups and fixes. TPEBS stands for Timed PEBS
     (Precision Event-Based Sampling), that adds timing info, the
     retirement latency of instructions

   - Various memory allocation (some detected by ASAN) and reference
     counting fixes

   - Add a 8-byte aligned PERF_RECORD_COMPRESSED2 to replace
     PERF_RECORD_COMPRESSED

   - Skip unsupported event types in perf.data files, don't stop when
     finding one

   - Improve lookups using hashmaps and binary searches"

* tag 'perf-tools-for-v6.16-1-2025-06-03' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools: (206 commits)
  perf callchain: Always populate the addr_location map when adding IP
  perf lock contention: Reject more than 10ms delays for safety
  perf trace: Set errpid to false for rseq and set_robust_list
  perf symbol: Move demangling code out of symbol-elf.c
  perf trace: Always print return value for syscalls returning a pid
  perf script: Print PERF_AUX_FLAG_COLLISION flag
  perf mem: Show absolute percent in mem_stat output
  perf mem: Display sort order only if it's available
  perf mem: Describe overhead calculation in brief
  perf record: Fix incorrect --user-regs comments
  Revert "perf thread: Ensure comm_lock held for comm_list"
  perf test trace_summary: Skip --bpf-summary tests if no libbpf
  perf test intel-pt: Skip jitdump test if no libelf
  perf intel-tpebs: Avoid race when evlist is being deleted
  perf test demangle-java: Don't segv if demangling fails
  perf symbol: Fix use-after-free in filename__read_build_id
  perf pmu: Avoid segv for missing name/alias_name in wildcarding
  perf machine: Factor creating a "live" machine out of dwarf-unwind
  perf test: Add AMD IBS sw filter test
  perf mem: Count L2 HITM for c2c statistic
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull perf tools updates from Arnaldo Carvalho de Melo:
 "perf report/top/annotate TUI:

   - Accept the left arrow key as a Zoom out if done on the first column

   - Show if source code toggle status in title, to help spotting bugs
     with the various disassemblers (capstone, llvm, objdump)

   - Provide feedback on unhandled hotkeys

  Build:

   - Better inform when certain features are not available with warnings
     in the build process and in 'perf version --build-options' or 'perf -vv'

  perf record:

   - Improve the --off-cpu code by synthesizing events for switch-out -&gt;
     switch-in intervals using a BPF program. This can be fine tuned
     using a --off-cpu-thresh knob

  perf report:

   - Add 'tgid' sort key

  perf mem/c2c:

   - Add 'op', 'cache', 'snoop', 'dtlb' output fields

   - Add support for 'ldlat' on AMD IBS (Instruction Based Sampling)

  perf ftrace:

   - Use process/session specific trace settings instead of messing with
     the global ftrace knobs

  perf trace:

   - Implement syscall summary in BPF

   - Support --summary-mode=cgroup

   - Always print return value for syscalls returning a pid

   - The rseq and set_robust_list don't return a pid, just -errno

  perf lock contention:

   - Symbolize zone-&gt;lock using BTF

   - Add -J/--inject-delay option to estimate impact on application
     performance by optimization of kernel locking behavior

  perf stat:

   - Improve hybrid support for the NMI watchdog warning

  Symbol resolution:

   - Handle 'u' and 'l' symbols in /proc/kallsyms, resolving some Rust
     symbols

   - Improve Rust demangler

  Hardware tracing:

  Intel PT:

   - Fix PEBS-via-PT data_src

   - Do not default to recording all switch events

   - Fix pattern matching with python3 on the SQL viewer script

  arm64:

   - Fixups for the hip08 hha PMU

  Vendor events:

   - Update Intel events/metrics files for alderlake, alderlaken,
     arrowlake, bonnell, broadwell, broadwellde, broadwellx,
     cascadelakex, clearwaterforest, elkhartlake, emeraldrapids,
     grandridge, graniterapids, haswell, haswellx, icelake, icelakex,
     ivybridge, ivytown, jaketown, lunarlake, meteorlake, nehalemep,
     nehalemex, rocketlake, sandybridge, sapphirerapids, sierraforest,
     skylake, skylakex, snowridgex, tigerlake, westmereep-dp,
     westmereep-sp, westmereep-sx

  python support:

   - Add support for event counts in the python binding, add a
     counting.py example

  perf list:

   - Display the PMU name associated with a perf metric in JSON

  perf test:

   - Hybrid improvements for metric value validation test

   - Fix LBR test by ignoring idle task

   - Add AMD IBS sw filter ana d'ldlat' tests

   - Add 'perf trace --summary-mode=cgroup' test

   - Add tests for the various language symbol demanglers

  Miscellaneous:

   - Allow specifying the cpu an event will be tied using '-e
     event/cpu=N/'

   - Sync various headers with the kernel sources

   - Add annotations to use clang's -Wthread-safety and fix some
     problems it detected

   - Make dump_stack() use perf's symbol resolution to provide better
     backtraces

   - Intel TPEBS support cleanups and fixes. TPEBS stands for Timed PEBS
     (Precision Event-Based Sampling), that adds timing info, the
     retirement latency of instructions

   - Various memory allocation (some detected by ASAN) and reference
     counting fixes

   - Add a 8-byte aligned PERF_RECORD_COMPRESSED2 to replace
     PERF_RECORD_COMPRESSED

   - Skip unsupported event types in perf.data files, don't stop when
     finding one

   - Improve lookups using hashmaps and binary searches"

* tag 'perf-tools-for-v6.16-1-2025-06-03' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools: (206 commits)
  perf callchain: Always populate the addr_location map when adding IP
  perf lock contention: Reject more than 10ms delays for safety
  perf trace: Set errpid to false for rseq and set_robust_list
  perf symbol: Move demangling code out of symbol-elf.c
  perf trace: Always print return value for syscalls returning a pid
  perf script: Print PERF_AUX_FLAG_COLLISION flag
  perf mem: Show absolute percent in mem_stat output
  perf mem: Display sort order only if it's available
  perf mem: Describe overhead calculation in brief
  perf record: Fix incorrect --user-regs comments
  Revert "perf thread: Ensure comm_lock held for comm_list"
  perf test trace_summary: Skip --bpf-summary tests if no libbpf
  perf test intel-pt: Skip jitdump test if no libelf
  perf intel-tpebs: Avoid race when evlist is being deleted
  perf test demangle-java: Don't segv if demangling fails
  perf symbol: Fix use-after-free in filename__read_build_id
  perf pmu: Avoid segv for missing name/alias_name in wildcarding
  perf machine: Factor creating a "live" machine out of dwarf-unwind
  perf test: Add AMD IBS sw filter test
  perf mem: Count L2 HITM for c2c statistic
  ...
</pre>
</div>
</content>
</entry>
</feed>
