linux-kernel - Re: [PATCH V5] perf tools: adding support for address filters

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: <20160920074452.3935bf0cf96c2b098ceb8d6f@kernel.org>
Date:   Tue, 20 Sep 2016 07:44:52 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Adrian Hunter <adrian.hunter@...el.com>
Cc:     Mathieu Poirier <mathieu.poirier@...aro.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        jolsa@...nel.org, Arnaldo Carvalho de Melo <acme@...radead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH V5] perf tools: adding support for address filters

On Mon, 19 Sep 2016 09:15:40 +0300
Adrian Hunter <adrian.hunter@...el.com> wrote:

> On 17/09/16 16:33, Masami Hiramatsu wrote:
> > On Fri, 16 Sep 2016 09:32:43 -0600
> > Mathieu Poirier <mathieu.poirier@...aro.org> wrote:
> > 
> >> On 13 September 2016 at 17:25, Masami Hiramatsu <mhiramat@...nel.org> wrote:
> >>> On Tue, 13 Sep 2016 08:18:10 -0600
> >>> Mathieu Poirier <mathieu.poirier@...aro.org> wrote:
> >>>
> >>>> On 13 September 2016 at 04:01, Adrian Hunter <adrian.hunter@...el.com> wrote:
> >>>>> On 12/09/16 20:53, Mathieu Poirier wrote:
> >>>>>> This patch makes it possible to use the current filter
> >>>>>> framework with address filters.  That way address filters for
> >>>>>> HW tracers such as CoreSight and IntelPT can be communicated
> >>>>>> to the kernel drivers.
> >>>>>>
> >>>>>> Signed-off-by: Mathieu Poirier <mathieu.poirier@...aro.org>
> >>>>>>
> >>>>>> ---
> >>>>>> Changes for V5:
> >>>>>>  - Modified perf_evsel__append_filter() to take a string format
> >>>>>>    rather than an operation.
> >>>>>
> >>>>> Hope I'm not being a pain, but aren't there other places calling
> >>>>> perf_evsel__append_filter() that need to be changed.  Might make
> >>>>> sense as a separate patch.
> >>>>
> >>>> No no, you're right - I completely overlooked that.
> >>>>
> >>>> But shouldn't it be in the same patch?  That way a git bisect would
> >>>> stay consistent...
> >>>
> >>> You're right. Caller and callee should be changed in atomic.
> >>>
> >>> BTW, could you add document updates how the perf command line
> >>> will be changed, and also show the result in the patch description?
> >>
> >> This patch does not change anything on the perf command line.  It
> >> simply allows current options to succeed (as they should) rather than
> >> fail.
> > 
> > Yes, and it will make perf acceptable to pass --filter to CoreSight or
> > Intel PT events, or am I misunderstand?
> > If it is correct, could you give us an example how to pass it, since
> > tools/perf/Documentation/perf-record.txt says it is only for tracepoints?
> 
> I am adding support for symbols in the address filter.  I will send the
> patches soon, but the documentation will be:
> 
> --filter=<filter>::
>         Event filter. This option should follow a event selector (-e) which
> 	selects either tracepoint event(s) or a hardware trace PMU
> 	(e.g. Intel PT or CoreSight).
> 
> 	- tracepoint filters
> 
> 	In the case of tracepoints, multiple '--filter' options are combined
> 	using '&&'.
> 
> 	- address filters
> 
> 	A hardware trace PMU advertises its ability to accept a number of
> 	address filters	by specifying a non-zero value in
> 	/sys/bus/event_source/devices/<pmu>/nr_addr_filters.
> 
> 	Address filters have the format:
> 	
> 	filter|start|stop|tracestop <start> [/ <size>] [@<file name>]
> 	
> 	Where:
> 	- 'filter': defines a region that will be traced.
> 	- 'start': defines an address at which tracing will begin.
> 	- 'stop': defines an address at which tracing will stop.
> 	- 'tracestop': defines a region in which tracing will stop.
> 
> 	<file name> is the name of the object file, <start> is the offset to the
> 	code to trace in that file, and <size> is the size of the region to
> 	trace. 'start' and 'stop' filters need not specify a <size>.
> 
> 	If no object file is specified then the kernel is assumed, in which case
> 	the start address must be a current kernel memory address.
> 
> 	<start> can also be specified by providing the name of a symbol. If the
> 	symbol name is not unique, it can be disambiguated by inserting #n where
> 	'n' selects the n'th symbol in address order. Alternately #0, #g or #G
> 	select only a global symbol. <size> can also be specified by providing
> 	the name of a symbol, in which case the size is calculated to the end
> 	of that symbol. For 'filter' and 'tracestop' filters, if <size> is
> 	omitted and <start> is a symbol, then the size is calculated to the end
> 	of that symbol.
> 
> 	If <size> is omitted and <start> is '*', then the start and size will
> 	be calculated from the first and last symbols, i.e. to trace the whole
> 	file.
> 
> 	If symbol names (or "*") are provided, they must be surrounded by white
> 	space.
> 
> 	The filter passed to the kernel is not necessarily the same as entered.
> 	To see the filter that is passed, use the -v option.
> 
> 	The kernel may not be able to configure a trace region if it is not
> 	within a single mapping.  MMAP events (or /proc/<pid>/maps) can be
> 	examined to determine if that is a possibility.
> 
> 	Multiple filters can be separated with space or comma.

Perfect! :)
OK, I'll wait your patch.

Thank you,

-- 
Masami Hiramatsu <mhiramat@...nel.org>