linux-kernel - Re: [PATCH v2 5/7] perf: Introduce address range filtering

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]

Message-ID: <CANLsYkzsqvCXgm37CsB9Cq4Mn8YopPN682KpadRB0gvmkXn9vQ@mail.gmail.com>
Date:	Mon, 2 May 2016 08:31:12 -0600
From:	Mathieu Poirier <mathieu.poirier@...aro.org>
To:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
	Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	vince@...ter.net, Stephane Eranian <eranian@...gle.com>,
	Arnaldo Carvalho de Melo <acme@...radead.org>
Subject: Re: [PATCH v2 5/7] perf: Introduce address range filtering

On 29 April 2016 at 22:59, Alexander Shishkin
<alexander.shishkin@...ux.intel.com> wrote:
> Mathieu Poirier <mathieu.poirier@...aro.org> writes:
>
>> I see two things in this work:
>
> [trimmed 700+ lines of context that had no purpose]
>
>> 1) A framework to deal with filters described in user space.
>> 2) An implementation for address filtering that will work for both
>> Intel and ARM.
>>
>> This will work well for address filtering (for both PT and CS) but
>> what happens when we want to introduce new filters?  This is
>> inevitable and some filters will be architecture agnostic while others
>> architecture specific.
>
> Haven't we been through this [1] already?
>
> [1] http://marc.info/?l=linux-kernel&m=145013911827358

Right, my comment was about improving the current solution and making
future changes less painful.  In my previous answer I should have made
it clearer that the current code will work for CoreSight and can go in
as is.  Now its up to Peter to decide what he wants to do.

With regards to how this solution fits in with instruction tracing for
other architectures, i.e ARM:

Reviewed-by: Mathieu Poirier <mathieu.poirier@...aro.org>

>
> Regards,
> --
> Alex