From: Arnaldo Carvalho de Melo <a...@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 <da...@davemloft.net>

:-)

Reply via email to