linux-kernel - Re: [RFC PATCH v3 00/37] perf tools: introduce 'perf bpf' command to load eBPF programs.

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: <20150518212013.GB13946@kernel.org>
Date:	Mon, 18 May 2015 18:20:13 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Alexei Starovoitov <ast@...mgrid.com>
Cc:	Wang Nan <wangnan0@...wei.com>, paulus@...ba.org,
	a.p.zijlstra@...llo.nl, mingo@...hat.com, namhyung@...nel.org,
	jolsa@...nel.org, dsahern@...il.com, daniel@...earbox.net,
	brendan.d.gregg@...il.com, masami.hiramatsu.pt@...achi.com,
	lizefan@...wei.com, linux-kernel@...r.kernel.org, pi3orama@....com
Subject: Re: [RFC PATCH v3 00/37] perf tools: introduce 'perf bpf' command to
 load eBPF programs.

Em Mon, May 18, 2015 at 02:05:35PM -0700, Alexei Starovoitov escreveu:
> On 5/18/15 1:44 PM, Arnaldo Carvalho de Melo wrote:
> >
> >perf record --filter, to pass a filter to tracepoints, if I could
> >instead of a filter expression pass, say, filter_bpf.o, that would seem
> >natural for me, i.e. no new option, just an alternative type of filter,
> >one way more powerful.
> ...
> >I'd say keep it in --filter, that noticing it is a bpf object would
> >dtrt:
> >
> >   perf record --filter bpf_thing.o usleep 1
> >
> 
> agree. make sense.
> The only thing is that such bpf program defines both event and filter.
> Existing --filter applies to --event, whereas this bpf_thing.o does both
> and likely kprob-ing multiple events underneath.
> I guess '--filter' still fits. Just need to document it clearly.

Humm, unsure then, because it is not a filter anymore, i.e. it is both a
filter and event selector :-\

I was thinking more like, hey, for an existing event, i.e. a place in
the kernel where it will collect something, collect if this filter
returns true. That would fit the existing --filter semantic.

 perf record --event bpf_thing.o

Looks more natural then, as it is an event that will take place when the
filter returns true, and in addition to that, it will come with a bunch
of variables, etc.

And if that is the case, then what is the difference from a kprobe
event? I.e. for the existing tooling it wouldn't matter how this event
was set up, as long as it was available via tracefs, etc. I.e. it would
be completely similar to a tracepoint, kprobe, uprobe, etc, i.e. first
set it up, expose its internals via tracefs, no changes to perf.

I must be missing something... But then it would happen when I would try
to deal with this eBPF thing, bear with me :-)

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