linux-kernel - Re: [PATCH] perf: Fix display of kernel symbols

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAP-5=fX2mr_N8fqScrb9Sr4b+Y726J9StGn7T3_Qfx36-Q=T5A@mail.gmail.com>
Date: Mon, 6 Jan 2025 12:24:02 -0800
From: Ian Rogers <irogers@...gle.com>
To: Christophe Leroy <christophe.leroy@...roup.eu>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, 
	Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>, 
	Mark Rutland <mark.rutland@....com>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>, 
	Adrian Hunter <adrian.hunter@...el.com>, "Liang, Kan" <kan.liang@...ux.intel.com>, 
	linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linuxppc-dev@...ts.ozlabs.org, Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [PATCH] perf: Fix display of kernel symbols

On Mon, Jan 6, 2025 at 11:38 AM Christophe Leroy
<christophe.leroy@...roup.eu> wrote:
>
> Since commit 659ad3492b91 ("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.
>
> Fixes: 659ad3492b91 ("perf maps: Switch from rbtree to lazily sorted array for addresses")
> Signed-off-by: Christophe Leroy <christophe.leroy@...roup.eu>
> Reviewed-by: Arnaldo Carvalho de Melo <acme@...hat.com>
> ---
>  tools/perf/util/maps.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/maps.c b/tools/perf/util/maps.c
> index 432399cbe5dd..d39bf27a5fdd 100644
> --- a/tools/perf/util/maps.c
> +++ b/tools/perf/util/maps.c
> @@ -1137,7 +1137,7 @@ struct map *maps__find_next_entry(struct maps *maps, struct map *map)
>
>         down_read(maps__lock(maps));
>         i = maps__by_address_index(maps, map);
> -       if (i < maps__nr_maps(maps))
> +       if (++i < maps__nr_maps(maps))
>                 result = map__get(maps__maps_by_address(maps)[i]);

Thanks for diagnosing this and sorry for the bug! Using the next entry
in this way won't work if the entries aren't sorted. I think the code
needs to be a little more complex, something like:
```
while (1) {
    down_read(maps__lock(maps));
    if (!maps__maps_by_address_sorted(maps)) {
        up_read(maps__lock(maps));
        maps__sort_by_address(maps);
        continue;
    }
    i = maps__by_address_index(maps, map) + 1;
    if (i < maps__nr_maps(maps))
        result = map__get(maps__maps_by_address(maps)[i]);
    up_read(maps__lock(maps));
    break;
}
```
We could also implement the code similar to maps__by_address_index but
with some kind of best next value in the unsorted case. Given the
function has a single caller then this is probably overkill, but we've
seen performance issues in this code before.

Thanks,
Ian