lkml.org 
[lkml]   [2018]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: perf's handling of unfindable user symbols...
From
From: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Tue, 16 Oct 2018 15:45:06 -0300

> Exec summary: yeah, drop that hack, I agree, patch at the end of the
> message.
>
> So, I thought something had changed and in the past we would somehow
> find that address in the kallsyms, but I couldn't find anything to back
> that up, the patch introducing this is over a decade old, lots of things
> changed, so I was just thinking I was missing something.
>
> I tried a gtod busy loop to generate vdso activity and added a 'perf
> probe' at that branch, on x86_64 to see if it ever gets hit:

Good, thanks for doing the detailed checking!

> In the process I noticed a bug, we're only have records for '[vdso]' for
> pre-existing commands, i.e. ones that are running when we start 'perf top',
> when we will generate the PERF_RECORD_MMAP by looking at /perf/PID/maps.

Hmmm. vdso mappings are installed by __install_special_mapping()
which should be emitting proper mmap events by calling
perf_event_mmap(vma).

Maybe the event is emitted too early? It doesn't look like it. These
are emitted after load_elf_binary() iterates over the PHDRs and
mmap()'s those areas of the binary, and we definitely see those events
properly.

> The kernel doesn't seem to be generating a PERF_RECORD_MMAP for vDSOs... And
> we can't do this in 'perf record' because we don't process event by event, just
> dump things from the ring buffer to a file...

It should be, see above.

> diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
> index 0988eb3b844b..bc646185f8d9 100644
> --- a/tools/perf/util/event.c
> +++ b/tools/perf/util/event.c
> @@ -1561,26 +1561,9 @@ struct map *thread__find_map(struct thread *thread, u8 cpumode, u64 addr,
>
> return NULL;
> }
> -try_again:
> +
> al->map = map_groups__find(mg, al->addr);
> - if (al->map == NULL) {
> - /*
> - * If this is outside of all known maps, and is a negative
> - * address, try to look it up in the kernel dso, as it might be
> - * a vsyscall or vdso (which executes in user-mode).
> - *
> - * XXX This is nasty, we should have a symbol list in the
> - * "[vdso]" dso, but for now lets use the old trick of looking
> - * in the whole kernel symbol list.
> - */
> - if (cpumode == PERF_RECORD_MISC_USER && machine &&
> - mg != &machine->kmaps &&
> - machine__kernel_ip(machine, al->addr)) {
> - mg = &machine->kmaps;
> - load_map = true;
> - goto try_again;
> - }
> - } else {
> + if (al->map != NULL) {
> /*
> * Kernel maps might be changed when loading symbols so loading
> * must be done prior to using kernel maps.
>
>

Acked-by: David S. Miller <davem@davemloft.net>

:-)

\
 
 \ /
  Last update: 2018-10-16 21:03    [W:0.117 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site