linux-kernel - Re: [PATCH 01/47] perf: Add PERF_EVENT_IOC

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:	Sat, 10 Aug 2013 14:11:17 +0200
From:	Jiri Olsa <jolsa@...hat.com>
To:	Vince Weaver <vince@...ter.net>
Cc:	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Paul Mackerras <paulus@...ba.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [PATCH 01/47] perf: Add PERF_EVENT_IOC_ID ioctl to return event
 ID

On Fri, Aug 09, 2013 at 10:50:27AM -0400, Vince Weaver wrote:
> On Wed, 7 Aug 2013, Arnaldo Carvalho de Melo wrote:
> 
> > From: Jiri Olsa <jolsa@...hat.com>
> > 
> > The only way to get the event ID is by reading the event fd,
> > followed by parsing the ID value out of the returned data.
> > 
> > While this is ok for current read format used by perf tool,
> > it is not ok when we use PERF_FORMAT_GROUP format.
> > 
> > With this format the data are returned for the whole group
> > and there's no way to find out what ID belongs to our fd
> > (if we are not group leader event).
> 
> I'm a little confused by this.
> 
> If you have an event group (with PERF_FORMAT_GROUP) and you specify
> PERF_FORMAT_ID in read_format, then when you read you get the id
> values for each sibling event along with their values, right?
> 
> This is how PAPI does things.  So I wouldn't say it's impossible to get 
> the event IDs with PERF_FORMAT_GROUP events.
> 
> Though maybe you're saying it's hard to map sibling fds to id values if 
> you don't have the list of all fds in an event group in the order they 
> were added.  Which I guess may be true, but I'd think your analysis tool 
> would have other problems if you didn't have that mapping.

right, the idea behind is not to be dependent
on how kernel chains events in the list

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/