linux-kernel - Re: [PATCH] perf record: Enable PERF_SAMPLE

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]

Message-ID: <20091023061827.GA1389@elte.hu>
Date:	Fri, 23 Oct 2009 08:18:27 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Anton Blanchard <anton@...ba.org>, Tom Zanussi <tzanussi@...il.com>
Cc:	paulus@...ba.org, a.p.zijlstra@...llo.nl,
	linux-kernel@...r.kernel.org, fweisbec@...il.com, acme@...hat.com
Subject: Re: [PATCH] perf record: Enable PERF_SAMPLE_ID when sampling
	multiple events

* Anton Blanchard <anton@...ba.org> wrote:

> 
> Hi Ingo,
> 
> > > If we are sampling multiple events we need the id in each sample so we 
> > > can differentiate between them in a perf data file.
> > 
> > Wondering, what are you (or will you be) using this for?
> 
> I put together a simple python library for parsing perf.data files:
> 
> http://ozlabs.org/~anton/junkcode/perf_event.py
> 
> An example of using it is here:
> 
> http://ozlabs.org/~anton/junkcode/perf_event_example.py
> 
> Only tested on powerpc so far, but it should work on x86. It's still 
> missing bits but it has been useful for finding some corner cases in 
> perf_event. It should also make it easy to post process complex 
> profiles with multiple events in them.

Ah, cool!

Note, there's a related development: we are working on script extensions 
to perf, in a built-in way. It can be found in this patch series from 
Tom on lkml:

  [RFC][PATCH 0/9] perf trace: support for general-purpose scripting

Tom started with Perl support - Python could be another script engine to 
add.

Now, your perf_event_example.py library goes deeper and exposes the 
perf.data itself as an independent codepath. I _think_ Tom's approach 
gives us a bit of an extra value by allowing us to tweak the environment 
of scripts with each perf version - i.e. we can iterate the perf.data 
format in the future without breaking scripts.

We are not ready yet to declare perf.data an ABI, and there's a few 
changes in tip:perf/* that might break the python library.

Also, as your fix demonstrates it, there's extra value in going 
ab-initio as well. Just wanted to mention the scripting engine work to 
couple perf with scriptlets, in case you find it interesting. We could 
easily do both.

> One problem this has just found though, is with PERF_EVENT_SAMPLE:
> 
> 	# FIXME: If sampling multiple events we have an issue
> 	# here. Since the SAMPLE_ID is not the first optional field
> 	# it might be impossible to differentiate between
> 	# events since the SAMPLE_ID field would be at different
> 	# offsets. For now we assume all events use the same
> 	# set of optional fields.
> 	eventnr = 0
> 	self.event = sample_event(eventbuf,
> 			self.header.attrs[eventnr].sample_type)
> 
> It seems like the API allows us to specify different sample options 
> for different events, but since the ID isnt the first option it could 
> end up in different places in different events, making it difficult 
> (if not impossible in some cases) to tag events correctly.

Could we fix this bug at the kernel level somehow, to imply SAMPLE_ID 
automatically? Producing a stream of data that cannot be decoded in some 
cases does not look smart.

	Ingo
--
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/