When loading kcore, the main vmlinux map is updated in the same loop
that merges the remaining maps. If a map that overlaps is merged in
before kcore, the list can become unsortable when the main map addresses
are updated. This will later trigger the check_invariants() assert:
$ perf record
$ perf report
util/maps.c:96: check_invariants: Assertion `map__end(prev) <=
map__start(map) || map__start(prev) == map__start(map)' failed.
Aborted
Fix it by moving the main map update prior to the loop so that
maps__merge_in() can split it if necessary.
Fixes: 659ad3492b91 ("perf maps: Switch from rbtree to lazily sorted array for addresses")
Signed-off-by: James Clark <james.clark@arm.com>
---
tools/perf/util/symbol.c | 40 +++++++++++++++++++++-------------------
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 2d95f22d713d..e98dfe766da3 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1289,7 +1289,7 @@ static int dso__load_kcore(struct dso *dso, struct map *map,
{
struct maps *kmaps = map__kmaps(map);
struct kcore_mapfn_data md;
- struct map *replacement_map = NULL;
+ struct map *map_ref, *replacement_map = NULL;
struct machine *machine;
bool is_64_bit;
int err, fd;
@@ -1367,6 +1367,24 @@ static int dso__load_kcore(struct dso *dso, struct map *map,
if (!replacement_map)
replacement_map = list_entry(md.maps.next, struct map_list_node, node)->map;
+ /*
+ * Update addresses of vmlinux map. Re-insert it to ensure maps are
+ * correctly ordered. Do this before using maps__merge_in() for the
+ * remaining maps so vmlinux gets split if necessary.
+ */
+ map_ref = map__get(map);
+ maps__remove(kmaps, map_ref);
+
+ map__set_start(map_ref, map__start(replacement_map));
+ map__set_end(map_ref, map__end(replacement_map));
+ map__set_pgoff(map_ref, map__pgoff(replacement_map));
+ map__set_mapping_type(map_ref, map__mapping_type(replacement_map));
+
+ err = maps__insert(kmaps, map_ref);
+ map__put(map_ref);
+ if (err)
+ goto out_err;
+
/* Add new maps */
while (!list_empty(&md.maps)) {
struct map_list_node *new_node = list_entry(md.maps.next, struct map_list_node, node);
@@ -1374,24 +1392,8 @@ static int dso__load_kcore(struct dso *dso, struct map *map,
list_del_init(&new_node->node);
- if (RC_CHK_EQUAL(new_map, replacement_map)) {
- struct map *map_ref;
-
- /* Ensure maps are correctly ordered */
- map_ref = map__get(map);
- maps__remove(kmaps, map_ref);
-
- map__set_start(map_ref, map__start(new_map));
- map__set_end(map_ref, map__end(new_map));
- map__set_pgoff(map_ref, map__pgoff(new_map));
- map__set_mapping_type(map_ref, map__mapping_type(new_map));
-
- err = maps__insert(kmaps, map_ref);
- map__put(map_ref);
- map__put(new_map);
- if (err)
- goto out_err;
- } else {
+ /* skip if replacement_map, already inserted above */
+ if (!RC_CHK_EQUAL(new_map, replacement_map)) {
/*
* Merge kcore map into existing maps,
* and ensure that current maps (eBPF)
--
2.34.1On Tue, May 7, 2024 at 7:13 AM James Clark <james.clark@arm.com> wrote:
>
> When loading kcore, the main vmlinux map is updated in the same loop
> that merges the remaining maps. If a map that overlaps is merged in
> before kcore, the list can become unsortable when the main map addresses
> are updated. This will later trigger the check_invariants() assert:
>
> $ perf record
> $ perf report
>
> util/maps.c:96: check_invariants: Assertion `map__end(prev) <=
> map__start(map) || map__start(prev) == map__start(map)' failed.
> Aborted
>
> Fix it by moving the main map update prior to the loop so that
> maps__merge_in() can split it if necessary.
Looks like you and Leo are working on the same problem.
https://lore.kernel.org/r/20240505202805.583253-1-leo.yan@arm.com/
>
> Fixes: 659ad3492b91 ("perf maps: Switch from rbtree to lazily sorted array for addresses")
> Signed-off-by: James Clark <james.clark@arm.com>
> ---
> tools/perf/util/symbol.c | 40 +++++++++++++++++++++-------------------
> 1 file changed, 21 insertions(+), 19 deletions(-)
>
> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> index 2d95f22d713d..e98dfe766da3 100644
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
> @@ -1289,7 +1289,7 @@ static int dso__load_kcore(struct dso *dso, struct map *map,
> {
> struct maps *kmaps = map__kmaps(map);
> struct kcore_mapfn_data md;
> - struct map *replacement_map = NULL;
> + struct map *map_ref, *replacement_map = NULL;
> struct machine *machine;
> bool is_64_bit;
> int err, fd;
> @@ -1367,6 +1367,24 @@ static int dso__load_kcore(struct dso *dso, struct map *map,
> if (!replacement_map)
> replacement_map = list_entry(md.maps.next, struct map_list_node, node)->map;
>
> + /*
> + * Update addresses of vmlinux map. Re-insert it to ensure maps are
> + * correctly ordered. Do this before using maps__merge_in() for the
> + * remaining maps so vmlinux gets split if necessary.
> + */
> + map_ref = map__get(map);
> + maps__remove(kmaps, map_ref);
A nitpick. It'd be natural to use 'map' instead of 'map_ref'
(even if they are the same) since IIUC we want to remove
the old 'map' and update 'map_ref' then add it back.
> +
> + map__set_start(map_ref, map__start(replacement_map));
> + map__set_end(map_ref, map__end(replacement_map));
> + map__set_pgoff(map_ref, map__pgoff(replacement_map));
> + map__set_mapping_type(map_ref, map__mapping_type(replacement_map));
So here, replacement_map should not be NULL right?
Thanks,
Namhyung
> +
> + err = maps__insert(kmaps, map_ref);
> + map__put(map_ref);
> + if (err)
> + goto out_err;
> +
> /* Add new maps */
> while (!list_empty(&md.maps)) {
> struct map_list_node *new_node = list_entry(md.maps.next, struct map_list_node, node);
> @@ -1374,24 +1392,8 @@ static int dso__load_kcore(struct dso *dso, struct map *map,
>
> list_del_init(&new_node->node);
>
> - if (RC_CHK_EQUAL(new_map, replacement_map)) {
> - struct map *map_ref;
> -
> - /* Ensure maps are correctly ordered */
> - map_ref = map__get(map);
> - maps__remove(kmaps, map_ref);
> -
> - map__set_start(map_ref, map__start(new_map));
> - map__set_end(map_ref, map__end(new_map));
> - map__set_pgoff(map_ref, map__pgoff(new_map));
> - map__set_mapping_type(map_ref, map__mapping_type(new_map));
> -
> - err = maps__insert(kmaps, map_ref);
> - map__put(map_ref);
> - map__put(new_map);
> - if (err)
> - goto out_err;
> - } else {
> + /* skip if replacement_map, already inserted above */
> + if (!RC_CHK_EQUAL(new_map, replacement_map)) {
> /*
> * Merge kcore map into existing maps,
> * and ensure that current maps (eBPF)
> --
> 2.34.1
>
On 08/05/2024 05:10, Namhyung Kim wrote:
> On Tue, May 7, 2024 at 7:13 AM James Clark <james.clark@arm.com> wrote:
>>
>> When loading kcore, the main vmlinux map is updated in the same loop
>> that merges the remaining maps. If a map that overlaps is merged in
>> before kcore, the list can become unsortable when the main map addresses
>> are updated. This will later trigger the check_invariants() assert:
>>
>> $ perf record
>> $ perf report
>>
>> util/maps.c:96: check_invariants: Assertion `map__end(prev) <=
>> map__start(map) || map__start(prev) == map__start(map)' failed.
>> Aborted
>>
>> Fix it by moving the main map update prior to the loop so that
>> maps__merge_in() can split it if necessary.
>
> Looks like you and Leo are working on the same problem.
>
> https://lore.kernel.org/r/20240505202805.583253-1-leo.yan@arm.com/
>
Oops I should have checked the list. It looks like we can still take his
fix as well though, with an updated comment.
>>
>> Fixes: 659ad3492b91 ("perf maps: Switch from rbtree to lazily sorted array for addresses")
>> Signed-off-by: James Clark <james.clark@arm.com>
>> ---
>> tools/perf/util/symbol.c | 40 +++++++++++++++++++++-------------------
>> 1 file changed, 21 insertions(+), 19 deletions(-)
>>
>> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
>> index 2d95f22d713d..e98dfe766da3 100644
>> --- a/tools/perf/util/symbol.c
>> +++ b/tools/perf/util/symbol.c
>> @@ -1289,7 +1289,7 @@ static int dso__load_kcore(struct dso *dso, struct map *map,
>> {
>> struct maps *kmaps = map__kmaps(map);
>> struct kcore_mapfn_data md;
>> - struct map *replacement_map = NULL;
>> + struct map *map_ref, *replacement_map = NULL;
>> struct machine *machine;
>> bool is_64_bit;
>> int err, fd;
>> @@ -1367,6 +1367,24 @@ static int dso__load_kcore(struct dso *dso, struct map *map,
>> if (!replacement_map)
>> replacement_map = list_entry(md.maps.next, struct map_list_node, node)->map;
>>
>> + /*
>> + * Update addresses of vmlinux map. Re-insert it to ensure maps are
>> + * correctly ordered. Do this before using maps__merge_in() for the
>> + * remaining maps so vmlinux gets split if necessary.
>> + */
>> + map_ref = map__get(map);
>> + maps__remove(kmaps, map_ref);
>
> A nitpick. It'd be natural to use 'map' instead of 'map_ref'
> (even if they are the same) since IIUC we want to remove
> the old 'map' and update 'map_ref' then add it back.
>
Using map makes sense, I can update that.
>> +
>> + map__set_start(map_ref, map__start(replacement_map));
>> + map__set_end(map_ref, map__end(replacement_map));
>> + map__set_pgoff(map_ref, map__pgoff(replacement_map));
>> + map__set_mapping_type(map_ref, map__mapping_type(replacement_map));
>
> So here, replacement_map should not be NULL right?
>
Yes it shouldn't be. It would only be NULL if md.maps is empty, but
there's already an exit condition for that above.
Some of the other code also assumes node->map is always set, so it can't
be NULL that way either.
> Thanks,
> Namhyung
>
>> +
>> + err = maps__insert(kmaps, map_ref);
>> + map__put(map_ref);
>> + if (err)
>> + goto out_err;
>> +
>> /* Add new maps */
>> while (!list_empty(&md.maps)) {
>> struct map_list_node *new_node = list_entry(md.maps.next, struct map_list_node, node);
>> @@ -1374,24 +1392,8 @@ static int dso__load_kcore(struct dso *dso, struct map *map,
>>
>> list_del_init(&new_node->node);
>>
>> - if (RC_CHK_EQUAL(new_map, replacement_map)) {
>> - struct map *map_ref;
>> -
>> - /* Ensure maps are correctly ordered */
>> - map_ref = map__get(map);
>> - maps__remove(kmaps, map_ref);
>> -
>> - map__set_start(map_ref, map__start(new_map));
>> - map__set_end(map_ref, map__end(new_map));
>> - map__set_pgoff(map_ref, map__pgoff(new_map));
>> - map__set_mapping_type(map_ref, map__mapping_type(new_map));
>> -
>> - err = maps__insert(kmaps, map_ref);
>> - map__put(map_ref);
>> - map__put(new_map);
>> - if (err)
>> - goto out_err;
>> - } else {
>> + /* skip if replacement_map, already inserted above */
>> + if (!RC_CHK_EQUAL(new_map, replacement_map)) {
>> /*
>> * Merge kcore map into existing maps,
>> * and ensure that current maps (eBPF)
>> --
>> 2.34.1
>>
On 5/8/2024 10:14 AM, James Clark wrote:
[...]
>> Looks like you and Leo are working on the same problem.
>>
>> https://lore.kernel.org/r/20240505202805.583253-1-leo.yan@arm.com/
>>
>
> Oops I should have checked the list. It looks like we can still take his
> fix as well though, with an updated comment.
Sorry for duplicate work. I will resend my patch separately with refined
comment, as suggested by Adrian.
[...]
>>> @@ -1289,7 +1289,7 @@ static int dso__load_kcore(struct dso *dso, struct map *map,
>>> {
>>> struct maps *kmaps = map__kmaps(map);
>>> struct kcore_mapfn_data md;
>>> - struct map *replacement_map = NULL;
>>> + struct map *map_ref, *replacement_map = NULL;
>>> struct machine *machine;
>>> bool is_64_bit;
>>> int err, fd;
>>> @@ -1367,6 +1367,24 @@ static int dso__load_kcore(struct dso *dso, struct map *map,
>>> if (!replacement_map)
>>> replacement_map = list_entry(md.maps.next, struct map_list_node, node)->map;
As the 'replacement' map is mainly used to adjust the kernel's sections
between '_stext' and '_end', some arches might don't share the same issue with
Arm64. So it is a bit redundant for assignment 'replacement_map' if it is
NULL, we can consider to remove the above two lines.
>>>
>>> + /*
>>> + * Update addresses of vmlinux map. Re-insert it to ensure maps are
>>> + * correctly ordered. Do this before using maps__merge_in() for the
>>> + * remaining maps so vmlinux gets split if necessary.
>>> + */
>>> + map_ref = map__get(map);
>>> + maps__remove(kmaps, map_ref);
>>
>> A nitpick. It'd be natural to use 'map' instead of 'map_ref'
>> (even if they are the same) since IIUC we want to remove
>> the old 'map' and update 'map_ref' then add it back.
>>
>
> Using map makes sense, I can update that.
>
>>> +
>>> + map__set_start(map_ref, map__start(replacement_map));
>>> + map__set_end(map_ref, map__end(replacement_map));
>>> + map__set_pgoff(map_ref, map__pgoff(replacement_map));
>>> + map__set_mapping_type(map_ref, map__mapping_type(replacement_map));
>>
>> So here, replacement_map should not be NULL right?
>>
>
> Yes it shouldn't be. It would only be NULL if md.maps is empty, but
> there's already an exit condition for that above.
>
> Some of the other code also assumes node->map is always set, so it can't
> be NULL that way either.
Thus, we can consider to check condition for 'replacement' map is NULL or not.
if (replacement_map) {
list_del_init(&new_node->node);
map_ref = map__get(map);
maps__remove(kmaps, map_ref);
...
map__put(new_map);
if (err)
goto out_err;
free(new_node);
}
[...]
>>> @@ -1374,24 +1392,8 @@ static int dso__load_kcore(struct dso *dso, struct map *map,
>>>
>>> list_del_init(&new_node->node);
>>>
>>> - if (RC_CHK_EQUAL(new_map, replacement_map)) {
>>> - struct map *map_ref;
>>> -
>>> - /* Ensure maps are correctly ordered */
>>> - map_ref = map__get(map);
>>> - maps__remove(kmaps, map_ref);
>>> -
>>> - map__set_start(map_ref, map__start(new_map));
>>> - map__set_end(map_ref, map__end(new_map));
>>> - map__set_pgoff(map_ref, map__pgoff(new_map));
>>> - map__set_mapping_type(map_ref, map__mapping_type(new_map));
>>> -
>>> - err = maps__insert(kmaps, map_ref);
>>> - map__put(map_ref);
>>> - map__put(new_map);
>>> - if (err)
>>> - goto out_err;
>>> - } else {
>>> + /* skip if replacement_map, already inserted above */
>>> + if (!RC_CHK_EQUAL(new_map, replacement_map)) {
With above change, we don't need check 'replacement_map' at here.
Just extend a bit for considering a more clean fixing, we need to sort all
ranges in 'md.maps', this would be benefit for two things:
- We can fix up any map regions, not only limit to the 'replacement_map'. With
sorting maps in 'md.maps', we can totally remove the code for
'replacement_map'.
- We can report the potential issue caused by overlapping in the first place
rather than the assert log in check_invariants(). This is easier for later
debugging.
But current patch is good enough for me, I don't have strong opinion for this.
Thanks,
Leo
>>> /*
>>> * Merge kcore map into existing maps,
>>> * and ensure that current maps (eBPF)
>>> --
>>> 2.34.1
>>>
© 2016 - 2026 Red Hat, Inc.