linux-kernel - Re: [BUG] perf: intel_pt won't display kernel function

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]

Date:   Thu, 4 Apr 2019 17:08:55 +0000
From:   Song Liu <songliubraving@...com>
To:     Jiri Olsa <jolsa@...hat.com>
CC:     Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Andi Kleen <andi@...stfloor.org>,
        "jolsa@...nel.org" <jolsa@...nel.org>,
        "namhyung@...nel.org" <namhyung@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-perf-users@...r.kernel.org" <linux-perf-users@...r.kernel.org>,
        Andi Kleen <ak@...ux.intel.com>
Subject: Re: [BUG] perf: intel_pt won't display kernel function



> On Apr 4, 2019, at 5:25 AM, Jiri Olsa <jolsa@...hat.com> wrote:
> 
> On Thu, Apr 04, 2019 at 11:14:38AM +0200, Jiri Olsa wrote:
> 
> SNIP
> 
>> Program received signal SIGABRT, Aborted.
>> 0x00007ffff75e60f5 in raise () from /lib64/libc.so.6
>> Missing separate debuginfos, use: dnf debuginfo-install bzip2-libs-1.0.6-29.fc30.x86_64 elfutils-libelf-0.176-1.fc30.x86_64 elfutils-libs-0.176-1.fc30.x86_64 libgcc-9.0.1-0.10.fc30.x86_64 libunwind-1.3.1-2.fc30.x86_64 libxcrypt-4.4.4-2.fc30.x86_64 numactl-libs-2.0.12-2.fc30.x86_64 perl-libs-5.28.1-434.fc30.x86_64 python2-libs-2.7.16-1.fc30.x86_64 slang-2.3.2-5.fc30.x86_64 xz-libs-5.2.4-5.fc30.x86_64 zlib-1.2.11-15.fc30.x86_64
>> (gdb) bt
>> #0  0x00007ffff75e60f5 in raise () from /lib64/libc.so.6
>> #1  0x00007ffff75d0895 in abort () from /lib64/libc.so.6
>> #2  0x00007ffff75d0769 in __assert_fail_base.cold () from /lib64/libc.so.6
>> #3  0x00007ffff75de596 in __assert_fail () from /lib64/libc.so.6
>> #4  0x00000000004fc006 in refcount_sub_and_test (i=1, r=0x1224e88) at /home/jolsa/linux/tools/include/linux/refcount.h:131
>> #5  refcount_dec_and_test (r=0x1224e88) at /home/jolsa/linux/tools/include/linux/refcount.h:148
>> #6  map__put (map=0x1224df0) at util/map.c:299
>> #7  0x00000000004fdb95 in __maps__remove (map=0x1224df0, maps=0xb17d80) at util/map.c:953
>> #8  maps__remove (maps=0xb17d80, map=0x1224df0) at util/map.c:959
>> #9  0x00000000004f7d8a in map_groups__remove (map=<optimized out>, mg=<optimized out>) at util/map_groups.h:65
>> #10 machine__process_ksymbol_unregister (sample=<optimized out>, event=0x7ffff7279670, machine=<optimized out>) at util/machine.c:728
>> #11 machine__process_ksymbol (machine=<optimized out>, event=0x7ffff7279670, sample=<optimized out>) at util/machine.c:741
>> #12 0x00000000004fffbb in perf_session__deliver_event (session=0xb11390, event=0x7ffff7279670, tool=0x7fffffffc7b0, file_offset=13936) at util/session.c:1362
>> #13 0x00000000005039bb in do_flush (show_progress=false, oe=0xb17e80) at util/ordered-events.c:243
>> #14 __ordered_events__flush (oe=0xb17e80, how=OE_FLUSH__ROUND, timestamp=<optimized out>) at util/ordered-events.c:322
>> #15 0x00000000005005e4 in perf_session__process_user_event (session=session@...ry=0xb11390, event=event@...ry=0x7ffff72a4af8,
>>    file_offset=file_offset@...ry=191224) at util/session.c:1402
>> #16 0x000000000050091e in perf_session__process_event (file_offset=191224, event=0x7ffff72a4af8, session=0xb11390) at util/session.c:1529
>> #17 process_simple (session=session@...ry=0xb11390, event=event@...ry=0x7ffff72a4af8, file_offset=file_offset@...ry=191224) at util/session.c:1962
>> #18 0x0000000000501f44 in reader__process_events (prog=0x7fffffffc680, session=0xb11390, rd=<synthetic pointer>) at util/session.c:1931
>> #19 __perf_session__process_events (session=0xb11390) at util/session.c:1985
>> #20 perf_session__process_events (session=0xb11390) at util/session.c:2018
>> #21 0x000000000045bb42 in __cmd_script (script=0x7fffffffc7b0) at builtin-script.c:2429
>> #22 cmd_script (argc=<optimized out>, argv=<optimized out>) at builtin-script.c:3770
>> #23 0x00000000004a65cb in run_builtin (p=p@...ry=0x994918 <commands+408>, argc=argc@...ry=4, argv=argv@...ry=0x7fffffffe160) at perf.c:303
>> #24 0x000000000042da1e in handle_internal_command (argv=0x7fffffffe160, argc=4) at perf.c:355
>> #25 run_argv (argcp=<synthetic pointer>, argv=<synthetic pointer>) at perf.c:399
>> #26 main (argc=4, argv=0x7fffffffe160) at perf.c:521
> 

For some reason, I cannot repro this issue. I tried to load two
bpf programs with same name, but that doesn't trigger it either. 


> 
> we dont increase the map's reference for same name,
> which we need to.. I assume we we re able to hit this
> path with bpf maps/dso with same name
> 
> jirka

Does the following change fix the issue on your side?

Thanks,
Song

> 
> 
> ---
> diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
> index 58ae5fc1f0e9..cdc49113ba38 100644
> --- a/tools/perf/util/map.c
> +++ b/tools/perf/util/map.c
> @@ -929,10 +929,11 @@ static void __maps__insert_name(struct maps *maps, struct map *map)
> 		else if (rc  > 0)
> 			p = &(*p)->rb_right;
> 		else
> -			return;
> +			goto out;
> 	}
> 	rb_link_node(&map->rb_node_name, parent, p);
> 	rb_insert_color(&map->rb_node_name, &maps->names);
> +out:
> 	map__get(map);
> }
>