| 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
| ||
|
Date: Fri, 9 Mar 2018 16:29:19 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Martin Vuille <jpmv27@....com>
Cc: Kim Phillips <kim.phillips@....com>, Jiri Olsa <jolsa@...nel.org>,
"Christian Hansen (chansen3)" <chansen3@...co.com>,
"linux-perf-users@...r.kernel.org" <linux-perf-users@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
linux-kernel@...r.kernel.org,
Mathieu Poirier <mathieu.poirier@...aro.org>,
"Vuille, Martin (Martin)" <vmartin@...ya.com>
Subject: Re: [PATCH] perf tools arm64: Add libdw DWARF post unwind support
for ARM64
Em Fri, Mar 09, 2018 at 01:49:50PM -0500, Martin Vuille escreveu:
> Hi,
>
> I made two other submissions that may also have been overlooked:
>
> https://patchwork.kernel.org/patch/10211401/ -- This one has the S-o-B
Ok, replied to that one, I can't see where is it that the symfs is being
first appended, please clarify that in the patch commit log message.
> https://patchwork.kernel.org/patch/10211473/ -- RFC, was looking for comments, has the S-o-B
[RFC,1/1] perf annotate: Don't prepend symfs path to vmlinux path
So, lemme try to provide the precise steps to reproduce this problem:
[root@...et ~]# perf record -F 10000 sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.017 MB perf.data (11 samples) ]
[root@...et ~]# perf buildid-list
44d954246227536955cb1ecbe9ef2a05665876b6 /lib/modules/4.16.0-rc4/build/vmlinux
87ae276466bc68e958c9817f11d5e09f14510585 [vdso]
3113881229974f02113945e92c1a4d4f146e061c /usr/lib64/libc-2.26.so
[root@...et ~]#
then we go on and remove that buildid from the cache:
[root@...et ~]# perf record -F 10000 sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.017 MB perf.data (10 samples) ]
[root@...et ~]# perf report --dso \[kernel.vmlinux\] | grep -v ^# | head -5
38.00% sleep [k] filemap_map_pages
19.68% sleep [k] elf_map
2.69% perf [k] perf_iterate_ctx
0.29% perf [k] end_repeat_nmi
0.04% perf [k] native_sched_clock
[root@...et ~]#
[root@...et ~]# perf buildid-list
44d954246227536955cb1ecbe9ef2a05665876b6 /lib/modules/4.16.0-rc4/build/vmlinux
87ae276466bc68e958c9817f11d5e09f14510585 [vdso]
3113881229974f02113945e92c1a4d4f146e061c /usr/lib64/libc-2.26.so
[root@...et ~]# ls -la ~/.debug/.build-id/44/d954246227536955cb1ecbe9ef2a05665876b6
lrwxrwxrwx. 1 root root 77 Mar 9 16:14 /root/.debug/.build-id/44/d954246227536955cb1ecbe9ef2a05665876b6 -> ../../home/build/v4.16.0-rc4/vmlinux/44d954246227536955cb1ecbe9ef2a05665876b6
[root@...et ~]# ls -la ~/.debug/home/build/v4.16.0-rc4/vmlinux/44d954246227536955cb1ecbe9ef2a05665876b6/
total 510840
drwxr-xr-x. 2 root root 4096 Mar 9 16:14 .
drwxr-xr-x. 3 root root 4096 Mar 6 11:35 ..
-rwxr-xr-x. 1 root root 523085744 Mar 6 11:35 elf
-rw-r--r--. 1 root root 0 Mar 9 16:14 probes
[root@...et ~]# perf buildid-cache --remove /lib/modules/4.16.0-rc4/build/vmlinux
[root@...et ~]# ls -la ~/.debug/.build-id/44/d954246227536955cb1ecbe9ef2a05665876b6
ls: cannot access '/root/.debug/.build-id/44/d954246227536955cb1ecbe9ef2a05665876b6': No such file or directory
[root@...et ~]# ls -la ~/.debug/home/build/v4.16.0-rc4/vmlinux/44d954246227536955cb1ecbe9ef2a05665876b6/
ls: cannot access '/root/.debug/home/build/v4.16.0-rc4/vmlinux/44d954246227536955cb1ecbe9ef2a05665876b6/': No such file or directory
[root@...et ~]#
Ok, so now I do:
[root@...et ~]# perf annotate --stdio --vmlinux /lib/modules/4.16.0-rc4/build/vmlinux filemap_map_pages
Failed to open [kernel.kallsyms]_text, continuing without symbols
Error:
The perf.data file has no samples!
[root@...et ~]#
But I ran out of time today, this one needs a bit more investigation, I
couldn't get to that dso__disassemble_filename() in the above case :-\
> For https://patchwork.kernel.org/patch/10211483/, I'm not sure how to go about doing a reply to all.
So, no need for that, just state here that you provide your Signed-off-by: to
it and I'll add it, which is what I'm doing now since this seems to be your
intent, right?
I'll just add another Link: tag pointing to your reply to -this- message,
if it comes with a S-o-B for https://patchwork.kernel.org/patch/10211483/, ok?
- Arnaldo
> I had some email problems and was cut-off from the list for a while.
>
> MV
>
>
> On 03/09/18 13:24, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Mar 09, 2018 at 12:07:20PM -0600, Kim Phillips escreveu:
> > > On Fri, 9 Mar 2018 12:06:27 -0300
> > > Arnaldo Carvalho de Melo <acme@...nel.org> wrote:
> > >
> > > Hi Arnaldo,
> > >
> > > > Em Thu, Mar 08, 2018 at 09:10:30PM -0600, Kim Phillips escreveu:
> > > > > Based on prior work:
> > > > >
> > > > > https://lkml.org/lkml/2014/5/6/395
> > > > Thanks, looks good, applying.
> > > >
> > > > Jean, is everything ok with you on this?
> > > By now your email to Jean should have bounced with "The email account
> > > that you tried to reach does not exist." Removing Jean from Cc.
> > >
> > > It seems like you're applying patches. There are a couple that have
> > > slipped through the cracks: Can you please take a look at applying them?
> > >
> > > - "perf tools: Fixing uninitialised variable"
> > > https://patchwork.kernel.org/patch/10179381/
> > [acme@...et perf]$ git tag --contains d2785de15f1bd42d613d56bbac5a007e7293b874
> > perf-core-for-mingo-4.17-20180216
> >
> > commit d2785de15f1bd42d613d56bbac5a007e7293b874
> > Author: Mathieu Poirier <mathieu.poirier@...aro.org>
> > AuthorDate: Mon Feb 12 13:32:37 2018 -0700
> > Commit: Arnaldo Carvalho de Melo <acme@...hat.com>
> > CommitDate: Fri Feb 16 14:55:40 2018 -0300
> >
> > perf auxtrace arm: Fixing uninitialised variable
> > When working natively on arm64 the compiler gets pesky and complains
> > that variable 'i' is uninitialised, something that breaks the
> > compilation. Here no further checks are needed since variable
> > 'found_spe' can only be true if variable 'i' has been initialised as
> > part of the for loop.
> > Signed-off-by: Mathieu Poirier <mathieu.poirier@...aro.org>
> > Cc: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
> > Cc: Jin Yao <yao.jin@...ux.intel.com>
> > Cc: Namhyung Kim <namhyung@...nel.org>
> > Cc: Peter Zijlstra <peterz@...radead.org>
> > Cc: linux-arm-kernel@...ts.infradead.org
> > Link: http://lkml.kernel.org/r/1518467557-18505-4-git-send-email-mathieu.poirier@linaro.org
> > Signed-off-by: Arnaldo Carvalho de Melo <acme@...hat.com>
> >
> > diff --git a/tools/perf/arch/arm/util/auxtrace.c b/tools/perf/arch/arm/util/auxtrace.c
> > index 2323581b157d..fa639e3e52ac 100644
> > --- a/tools/perf/arch/arm/util/auxtrace.c
> > +++ b/tools/perf/arch/arm/util/auxtrace.c
> > @@ -68,7 +68,7 @@ struct auxtrace_record
> > bool found_spe = false;
> > static struct perf_pmu **arm_spe_pmus = NULL;
> > static int nr_spes = 0;
> > - int i;
> > + int i = 0;
> > > - "perf unwind: Report error from dwfl_attach_state"
> > > https://patchwork.kernel.org/patch/10211483/
> > > [Martin, I guess it would help if you replied-all that patch and
> > > added your signed-off-by.]
> > Right, the S-o-B is needed
> > > - "perf unwind: Unwind with libdw doesn't take symfs into account"
> > > https://patchwork.kernel.org/patch/10211599/
> > This one has the S-o-B, applying, Jiri, holler if you disagree,
> >
> > - Arnaldo
> > > Thanks,
> > >
> > > Kim
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
> > the body of a message to majordomo@...r.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists