From: Ian Rogers <irogers@google.com>
To: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
James Clark <james.clark@linaro.org>,
Zhan Xusheng <zhanxusheng1024@gmail.com>,
Dapeng Mi <dapeng1.mi@linux.intel.com>,
Aaron Tomlin <atomlin@atomlin.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH v1 4/7] perf maps: Check map__start_cmp() in __maps__insert()
Date: Sun, 25 Oct 2026 15:03:46 -0700 [thread overview]
Message-ID: <20261025220349.1244499-4-irogers@google.com> (raw)
In-Reply-To: <20261025220349.1244499-1-irogers@google.com>
In __maps__insert(), maps_by_address_sorted is kept true if the previous
map's end is less than or equal to the new map's start. However, when a
map has an end of 0 (for example, an unmapped [0, 0) map or a map whose
end has not been set yet) and a [0, 0) map is inserted after it,
map__end(prev) <= map__start(new) evaluates to 0 <= 0 (true) even when
map__start_cmp(&prev, &new) > 0 (either because map__start(prev) > 0 or
because prev's pointer address is greater than new's pointer address).
This leaves maps_by_address_sorted set to true on an array that is not
ordered according to map__start_cmp(), causing bsearch() in
maps__by_address_index() to fail and return -1 during __maps__remove().
Also check map__start_cmp(&maps_by_address[nr_maps - 2], &new) <= 0 when
updating maps_by_address_sorted in __maps__insert().
Fixes: 659ad3492b91 ("perf maps: Switch from rbtree to lazily sorted array for addresses")
Signed-off-by: Ian Rogers <irogers@google.com>
---
tools/perf/util/maps.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/maps.c b/tools/perf/util/maps.c
index f808df2fe77b..675fe0223faa 100644
--- a/tools/perf/util/maps.c
+++ b/tools/perf/util/maps.c
@@ -519,7 +519,8 @@ static int __maps__insert(struct maps *maps, struct map *new)
/* Sorted if maps were already sorted and this map starts after the last one. */
maps__set_maps_by_address_sorted(maps,
maps__maps_by_address_sorted(maps) &&
- map__end(maps_by_address[nr_maps - 2]) <= map__start(new));
+ map__end(maps_by_address[nr_maps - 2]) <= map__start(new) &&
+ map__start_cmp(&maps_by_address[nr_maps - 2], &new) <= 0);
maps__set_maps_by_name_sorted(maps, false);
}
if (map__end(new) < map__start(new))
--
2.56.0.307.g5fe7bd680c-goog
next prev parent reply other threads:[~2026-10-25 22:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-25 22:03 [PATCH v1 1/7] perf session: Fix minimum event size for PERF_RECORD_CALLCHAIN_DEFERRED Ian Rogers
2026-10-25 22:03 ` [PATCH v1 2/7] perf evsel: Add bounds check for PERF_RECORD_CALLCHAIN_DEFERRED ips array Ian Rogers
2026-10-25 22:45 ` sashiko-bot
2026-10-25 22:03 ` [PATCH v1 3/7] perf dso: Handle trailing zeros symmetrically in dso__build_id_equal() Ian Rogers
2026-10-25 22:43 ` sashiko-bot
2026-10-25 22:03 ` Ian Rogers [this message]
2026-10-25 22:42 ` [PATCH v1 4/7] perf maps: Check map__start_cmp() in __maps__insert() sashiko-bot
2026-10-25 22:03 ` [PATCH v1 5/7] perf inject: Use perf_tool__init() for --vm-time-correlation Ian Rogers
2026-10-25 22:47 ` sashiko-bot
2026-10-27 20:26 ` Aaron Tomlin
2026-10-25 22:03 ` [PATCH v1 6/7] perf inject: Set ordering_requires_timestamps before creating session Ian Rogers
2026-10-25 22:52 ` sashiko-bot
2026-10-27 20:27 ` Aaron Tomlin
2026-10-25 22:03 ` [PATCH v1 7/7] perf session: Check lbr_stack for NULL in callchain__lbr_callstack_printf() Ian Rogers
2026-10-25 22:50 ` sashiko-bot
2026-10-25 22:45 ` [PATCH v1 1/7] perf session: Fix minimum event size for PERF_RECORD_CALLCHAIN_DEFERRED sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261025220349.1244499-4-irogers@google.com \
--to=irogers@google.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=atomlin@atomlin.com \
--cc=dapeng1.mi@linux.intel.com \
--cc=james.clark@linaro.org \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=zhanxusheng1024@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.