Received-SPF: pass (google.com: domain of linux-kernel+bounces-172964-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <16116798-52d6-4004-8514-9b81c789474f@arm.com>
Date: Wed, 8 May 2024 10:14:31 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/4] perf symbols: Update kcore map before merging in
 remaining symbols
To: Namhyung Kim <namhyung@kernel.org>
Cc: linux-perf-users@vger.kernel.org, atrajeev@linux.vnet.ibm.com,
 irogers@google.com, Peter Zijlstra <peterz@infradead.org>,
 Ingo Molnar <mingo@redhat.com>, Arnaldo Carvalho de Melo <acme@kernel.org>,
 Mark Rutland <mark.rutland@arm.com>,
 Alexander Shishkin <alexander.shishkin@linux.intel.com>,
 Jiri Olsa <jolsa@kernel.org>, Adrian Hunter <adrian.hunter@intel.com>,
 "Liang, Kan" <kan.liang@linux.intel.com>, linux-kernel@vger.kernel.org
References: <20240507141210.195939-1-james.clark@arm.com>
 <20240507141210.195939-4-james.clark@arm.com>
 <CAM9d7cjYvMndUmSuwnE1ETwnu_6WrxQ4UzsNHHvo4SVR250L7A@mail.gmail.com>
Content-Language: en-US
From: James Clark <james.clark@arm.com>
In-Reply-To: <CAM9d7cjYvMndUmSuwnE1ETwnu_6WrxQ4UzsNHHvo4SVR250L7A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit


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
>>