linux-kernel - Re: Adding a filter to events (instead of replacing one) was Re: [PATCH 1/2] perf, tools: Add PERF

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20141001221306.GJ2799@kernel.org>
Date:	Wed, 1 Oct 2014 19:13:06 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Andi Kleen <ak@...ux.intel.com>
Cc:	Andi Kleen <andi@...stfloor.org>, jolsa@...hat.com,
	linux-kernel@...r.kernel.org, namhyung@...nel.org,
	Brendan Gregg <brendan.d.gregg@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: Adding a filter to events (instead of replacing one) was Re:
 [PATCH 1/2] perf, tools: Add PERF_PID

Em Wed, Oct 01, 2014 at 03:02:18PM -0700, Andi Kleen escreveu:
> On Wed, Oct 01, 2014 at 03:03:16PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Sep 24, 2014 at 01:51:08PM -0700, Andi Kleen escreveu:

> > > It's currently difficult to filter out perf itself using a filter.
> > > This can give cascading effects during IO tracing when the IO perf
> > > does itself causes more trace output.

> > > The best way to filter is to use the pid. But it's difficult to get the pid
> > > of perf without using hacks.

> > > Add a PERF_PID meta variable to the perf filter that contains the current pid.

> > > With this patch the following works

> > > % perf record -e syscalls:sys_enter_write -a --filter 'common_pid != PERF_PID' ...

> > So I tried this one now and saw the other patch, that applies the
> > --filter to all events, while trying I got:

> Patch seems reasonable to me.

> However adding PERF_PID and sanitizing --filter are really two
> different things and should probably not be mixed in a patch.

Yes, there are two things, but what seems to be wanted first is a way to
exclude 'perf record' samples, for all events.

Being able to specify PERF_PID on a filter so that some events can
include 'perf record' samples and some not seems to be something not
really needed at this point, i.e. just doing:

  perf record --filter-self -e syscalls:sys_enter_write -a ...

Is shorter and doesn't breaks the current --filter semantic (apply just
to the last tracepoint informed in the cmdline, not to all tracepoints)
like in your second patch.

So probably what is best to do is to finish the patch I sent here, which
will cover the filter-out-perf-tooling-samples usecase, and then, if
people still think it is needed, introduce the PERF_PID meta filter
variable.

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