linux-kernel - Re: [PATCH] perf report: fix event name reporting

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] [day] [month] [year] [list]

Date:	Tue, 12 Jun 2012 11:43:08 -0300
From:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
To:	Namhyung Kim <namhyung@...nel.org>,
	Dmitry Antipov <dmitry.antipov@...aro.org>
Cc:	Ingo Molnar <mingo@...hat.com>, Paul Mackerras <paulus@...ba.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org, linaro-dev@...ts.linaro.org,
	patches@...aro.org
Subject: Re: [PATCH] perf report: fix event name reporting

Em Tue, Jun 12, 2012 at 03:34:22PM +0900, Namhyung Kim escreveu:
> On Mon, 11 Jun 2012 11:14:16 -0300, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Jun 08, 2012 at 04:23:27PM +0400, Dmitry Antipov escreveu:
> >> Use trace_find_event to find event name before looking through
> >> /sys files. This helps 'perf report' to show real event names
> >> instead of 'unknown:unknown' when processing perf.data recorded
> >> on another machine.
> >
> > We have to somehow tell perf_evlist__tty_browse_hists that it should try
> > to figure out the name of the event by looking at _either_ /sys (local
> > events) or what came in the perf.data file.
> >
> > That is because 'perf top' and 'perf report' uses
> > perf_evlist__tty_browse_hists. One is for local events (top) and the
> > other for perf.data files, that may or not be for local (in the sense of
> > running the same kernel for record + report) or for "remote" (running on
> > the same machine but with a different kernel at record than the one used
> > at report) or from a different machine altogether, perhaps even
> > different arch.
> 
> I just thought that we should always consider the remote case first and
> falls back to local case because if we looked for local events, the
> remote events (perf.data) would not exist so that it can falls to the
> local case safely.
> 
> Now I think that we need a session method to check whether the current
> session is local or remote, and acts something based on that info.

We just need to get the data from the perf.data file as early as
possible, i.e. just after processing the perf.data headers, like in the
attached patch.

Dmitry, can you please try it?

- Arnaldo

View attachment "0001-perf-tools-Fix-synthesizing-tracepoint-names-from-th.patch" of type "text/plain" (3497 bytes)