linux-kernel - Re: [PATCH V6 20/26] perf: changing pmu::setup

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:	Fri, 11 Dec 2015 14:58:57 -0700
From:	Mathieu Poirier <mathieu.poirier@...aro.org>
To:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Chunyan Zhang <zhang.chunyan@...aro.org>,
	Mike Leach <mike.leach@....com>,
	"Jeremiassen, Tor" <tor@...com>, Al Grant <al.grant@....com>,
	fainelli@...adcom.com,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>, linux-doc@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: Re: [PATCH V6 20/26] perf: changing pmu::setup_aux() parameter to
 include event

On 11 December 2015 at 07:12, Alexander Shishkin
<alexander.shishkin@...ux.intel.com> wrote:
> Mathieu Poirier <mathieu.poirier@...aro.org> writes:
>
>> For Coresight ETMv3/4 tracers the event carries information
>> about trace modes such as user or kernel space tracing and
>> whether tracing is allowed when operating in secure mode.
>
> Ok, so it looks to me that what you're doing in your setup_aux with the
> event, you should rather be doing in pmu::event_init(), which takes
> event as a parameter and it even makes more sense semantically, because
> that bit is really configuring the parameters of tracing and not
> capturing, which setup_aux() is more about. And the above paragraph also
> sounds very much like it. Since in Coresight there is a very clear
> distinction between trace generation (sources) and capturing (sinks) it
> should also be possible to structure the code in such a way that the
> former are not as closely tied to the latter. Please correct me if I'm
> missing something.

Conceptually there is no need to do the configuration for source, path
and sink in setup_aux() but all this information has to be kept
somewhere...  Since setup_aux() is where the private data structure
that will be used for the rest of the trace session gets created I
didn't see another way.

But with your patchset on trace filtering [1] I'm pretty sure we don't
need to do tracer configuration for all the tracers at the beginning.
I have to double check a few things but it is very likely that CS
tracer configuration can be made the same way PT is done, something
that will seriously simplify the setup process.

That leaves us with the path from source to sink - it is event
specific and as such needs to be part of the private data structure.
Unless you see a better way to proceed it will stay in setup_aux...

Thanks for the review,
Mathieu

[1]. https://lkml.org/lkml/2015/12/11/449

>
> Regards,
> --
> Alex
--
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/