kernel/linux.git/tools/perf/util/maps.c, branch v6.19.11

perf maps: Fix reference count leak in maps__find_ams()

2026-03-04T12:19:26+00:00

[ Upstream commit 6fdd2676db55b503c52dd3f1359b5c57f774ab75 ] ams and so ams->ms.map is an in argument, however, it is also overwritten. As a map is reference counted, ensure a map__put() is done before overwriting it. Fixes: 42fd623b58dbcc48 ("perf maps: Get map before returning in maps__find") Reviewed-by: James Clark Signed-off-by: Ian Rogers Cc: Aditya Bodkhe Cc: Adrian Hunter Cc: Albert Ou Cc: Alexander Shishkin Cc: Alexandre Ghiti Cc: Athira Rajeev Cc: Bill Wendling Cc: Dr. David Alan Gilbert Cc: Guo Ren Cc: Howard Chu Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: John Garry Cc: Julia Lawall Cc: Justin Stitt Cc: Krzysztof Łopatowski Cc: Leo Yan Cc: Namhyung Kim Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Peter Zijlstra Cc: Sergei Trofimovich Cc: Shimin Guo Cc: Suchit Karunakaran Cc: Thomas Falcon Cc: Tianyou Li Cc: Will Deacon Cc: Zecheng Li Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin

perf maps: Avoid RC_CHK use after free

2025-11-20T00:20:15+00:00

The case of __maps__fixup_overlap_and_insert where the "new" maps covers existing mappings can create a use-after-free with reference count checking enabled. The issue is that "pos" holds a map pointer from maps_by_address that is put from maps_by_address but then used to look for a map in maps_by_name (the compared map is now a use-after-free). The issue stems from using maps__remove which redoes some of the searches already done by __maps__fixup_overlap_and_insert, so optimize the code (by avoiding repeated searches) and avoid the use-after-free by inlining the appropriate removal code. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202511141407.f9edcfa6-lkp@intel.com Signed-off-by: Ian Rogers Reviewed-by: James Clark Signed-off-by: Namhyung Kim

perf maps: Ensure kmap is set up for all inserts

2025-09-15T17:03:23+00:00

__maps__fixup_overlap_and_insert may split or directly insert a map, when doing this the map may need to have a kmap set up for the sake of the kmaps. The missing kmap set up fails the check_invariants test in maps, later "Internal error" reports from map__kmap and ultimately causes segfaults. Similar fixes were added in commit e0e4e0b8b7fa ("perf maps: Add missing map__set_kmap_maps() when replacing a kernel map") and commit 25d9c0301d36 ("perf maps: Set the kmaps for newly created/added kernel maps") but they missed cases. To try to reduce the risk of this, update the kmap directly following any manual insert. This identified another problem in maps__copy_from. Fixes: e0e4e0b8b7fa ("perf maps: Add missing map__set_kmap_maps() when replacing a kernel map") Fixes: 25d9c0301d36 ("perf maps: Set the kmaps for newly created/added kernel maps") Signed-off-by: Ian Rogers Signed-off-by: Namhyung Kim

perf record: Fix a asan runtime error in util/maps.c

2025-05-16T20:31:40+00:00

If I build perf with asan and run Zstd test: $ make -C tools/perf O=/tmp/perf DEBUG=1 EXTRA_CFLAGS="-O0 -g -fno-omit-frame-pointer -fsanitize=undefined" $ /tmp/perf/perf test "Zstd perf.data compression/decompression" -vv 83: Zstd perf.data compression/decompression: ... util/maps.c:1046:5: runtime error: null pointer passed as argument 2, which is declared to never be null ... The issue was caused by `bsearch`. The patch adds a check to ensure argument 2 and 3 are not NULL and 0. Testing with the commands above confirms that the runtime error is resolved. Reviewed-by: Ian Rogers Signed-off-by: Chun-Tse Shao Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ben Gainey Cc: Christophe Leroy Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Leo Yan Cc: Mark Rutland Cc: Namhyung Kim Cc: Nick Terrell Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20250303183646.327510-2-ctshao@google.com Signed-off-by: Arnaldo Carvalho de Melo

perf maps: Add missing map__set_kmap_maps() when replacing a kernel map

2025-03-06T07:03:43+00:00

Since in this case __maps__insert_sorted() is not called and thus doesn't have the opportunity to do the needed map__set_kmap_maps() calls on the new map. Signed-off-by: Arnaldo Carvalho de Melo Acked-by: Namhyung Kim Reviewed-by: Ian Rogers Link: https://lore.kernel.org/lkml/Z7-May5w9VQd5QD0@x1 Link: https://lore.kernel.org/r/20250228211734.33781-6-acme@kernel.org Signed-off-by: Namhyung Kim

perf maps: Fixup maps_by_name when modifying maps_by_address

2025-03-06T07:03:33+00:00

We can't just replacing the map in the maps_by_address and not touching on the maps_by_name, that would leave the refcount as 1 and thus trip another consistency check, this one: perf: util/maps.c:110: check_invariants: Assertion `refcount_read(map__refcnt(map)) > 1' failed. 106 /* 107 * Maps by name maps should be in maps_by_address, so 108 * the reference count should be higher. 109 */ 110 assert(refcount_read(map__refcnt(map)) > 1); Committer notice: Initialize the newly added 'ni' variable, that really can't be accessed unitialized trips some gcc versions, like: 12 20.00 archlinux:base : FAIL gcc version 13.2.1 20230801 (GCC) util/maps.c: In function ‘__maps__fixup_overlap_and_insert’: util/maps.c:896:54: error: ‘ni’ may be used uninitialized [-Werror=maybe-uninitialized] 896 | map__put(maps_by_name[ni]); | ^ util/maps.c:816:25: note: ‘ni’ was declared here 816 | unsigned int i, ni; | ^~ cc1: all warnings being treated as errors make[3]: *** [/git/perf-6.14.0-rc1/tools/build/Makefile.build:138: util] Error 2 Reported-by: Arnaldo Carvalho de Melo Tested-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers Link: https://lore.kernel.org/lkml/Z79std66tPq-nqsD@google.com Link: https://lore.kernel.org/r/20250228211734.33781-5-acme@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim

perf maps: Set the kmaps for newly created/added kernel maps

2025-03-06T07:03:11+00:00

When using __maps__insert_sorted() the map kmaps field needs to be initialized, as we need kernel maps to work with map__kmap(). Fix it by using the newly introduced map__set_kmap() method. Signed-off-by: Arnaldo Carvalho de Melo Acked-by: Namhyung Kim Reviewed-by: Ian Rogers Link: https://lore.kernel.org/lkml/Z74V0hZXrTLM6VIJ@x1 Link: https://lore.kernel.org/r/20250228211734.33781-3-acme@kernel.org Signed-off-by: Namhyung Kim

perf maps: Introduce map__set_kmap_maps() for kernel maps

2025-03-06T07:03:04+00:00

We need to set it in other places than __maps__insert(), so that we can have access to the 'struct maps' from a kernel 'struct map'. When building perf with 'DEBUG=1' we can notice it failing a consistency check done in the check_invariants() function: root@number:~# perf record -- perf test -w offcpu [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.040 MB perf.data (23 samples) ] perf: util/maps.c:95: check_invariants: Assertion `map__end(prev) <= map__end(map)' failed. Aborted (core dumped) root@number:~# The investigation on that was happening bisected to 876e80cf83d10585 ("perf tools: Fixup end address of modules"), and the following patches will plug the problems found, this patch is just legwork on that direction. Use the map__set_kmap_maps() name as per a review comment from Ian Rogers, later there are further suggestions from him on getting rid of the kmaps variable, see the thread referenced in the Link below. Signed-off-by: Arnaldo Carvalho de Melo Acked-by: Namhyung Kim Reviewed-by: Ian Rogers Link: https://lore.kernel.org/lkml/Z74V0hZXrTLM6VIJ@x1 Link: https://lore.kernel.org/r/20250228211734.33781-2-acme@kernel.org Signed-off-by: Namhyung Kim

perf maps: Fix display of kernel symbols

2025-01-08T20:20:42+00:00

Since commit 659ad3492b913c90 ("perf maps: Switch from rbtree to lazily sorted array for addresses"), perf doesn't display anymore kernel symbols on powerpc, allthough it still detects them as kernel addresses. # Overhead Command Shared Object Symbol # ........ .......... ............. ...................................... # 80.49% Coeur main [unknown] [k] 0xc005f0f8 3.91% Coeur main gau [.] engine_loop.constprop.0.isra.0 1.72% Coeur main [unknown] [k] 0xc005f11c 1.09% Coeur main [unknown] [k] 0xc01f82c8 0.44% Coeur main libc.so.6 [.] epoll_wait 0.38% Coeur main [unknown] [k] 0xc0011718 0.36% Coeur main [unknown] [k] 0xc01f45c0 This is because function maps__find_next_entry() now returns current entry instead of next entry, leading to kernel map end address getting mis-configured with its own start address instead of the start address of the following map. Fix it by really taking the next entry, also make sure that entry follows current one by making sure entries are sorted. Fixes: 659ad3492b913c90 ("perf maps: Switch from rbtree to lazily sorted array for addresses") Reviewed-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers Signed-off-by: Christophe Leroy Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/2ea4501209d5363bac71a6757fe91c0747558a42.1736329923.git.christophe.leroy@csgroup.eu Signed-off-by: Arnaldo Carvalho de Melo

perf maps: Add/use a sorted insert for fixup overlap and insert

2024-06-07T06:31:30+00:00

Data may have lots of overlapping mmaps. The regular insert adds at the end and relies on a later sort. For data with overlapping mappings the sort will happen during a subsequent maps__find or __maps__fixup_overlap_and_insert, there's never a period where the inserted maps buffer up and a single sort happens. To avoid back to back sorts, maintain the sort order when fixing up and inserting. Previously the first_ending_after search was O(log n) where n is the size of maps, and the insert was O(1) but because of the continuous sorting was becoming O(n*log(n)). With maintaining sort order, the insert now becomes O(n) for a memmove. For a perf report on a perf.data file containing overlapping mappings the time numbers are: Before: real 0m5.894s user 0m5.650s sys 0m0.231s After: real 0m0.675s user 0m0.454s sys 0m0.196s Signed-off-by: Ian Rogers Reviewed-by: James Clark Cc: Steinar H . Gunderson Signed-off-by: Namhyung Kim Link: https://lore.kernel.org/r/20240521165109.708593-4-irogers@google.com