Re: [RFC PATCH v9 00/50] perf tools: filtering events using eBPF programs

[Wangnan (F)]

On 2015/6/27 6:44, Alexei Starovoitov wrote:
> On 6/26/15 7:15 AM, Wang Nan wrote:
> > This is the 9th version which tries to introduce eBPF programs to perf.
> >
> > This patchset combined with 2 patchset I posted:
> >
> >   1. V8 of 'perf tools: filtering events using eBPF programs';
> >
> >   2. 'tracing, perf tools: Attach BPF program on uprobe events'
> >
> > And patch 'tracing, perf: Implement BPF programs attached to uprobes' is
> > promoted to 1/50 since it belongs to kernel.
> >
> > As Alexei's suggestion, I squashed some patches together in order to
> > make patchset simpler. The affected patches including:
> >
> >   Patch 19/50: merged with 'bpf tools: Load instructions buffer using 
> > load_program()';
> >   Patch 35/50: merged with 'perf tools: Generate prologue for BPF 
> > programs'.
> >
> > In this version I corrected many coding style problems found by
> > checkpatch.pl. Most of them are minor change except patch 45/50, which
> > checkpatch doesn't allow me to use goto statement in a macro, so I have
> > to redesign error processing when prologue too long.
> >
> > Other changes including:
> >
> >   1. Correct compiling problem when CONFIG_BPF_PROLOGUE not set;
> >
> >   2. Config options for each BPF program is changed to 'key=value' from
> >      'key:value';
> >
> >   3. Improve error message when config string error (Patch 50/50).
> >
> > The 50 patches can be divided into following groups:
> >
> >   1. Patch 1/50 belog to kernel, which has been accepted by Alexei.
> >
> >   2. Patch 2/50 - 38/50 add basic BPF support to perf, which is from my
> >      v7 patch, only style correction and patch squashing is take place
> >      in this version.
> >
> >   3. Patch 39/50 - 48/50 add BPF prologue support which allow BPF 
> > programs
> >      to read kernel data.
> >
> >   4. Patch 49/50 - 50/50 are perf side code which allow attach BPF 
> > programs
> >      on uprobe event.
> >
> > To demonstrate the feature of the new patchset, I attach a sample eBPF
> > program below. This program can be used to analysis some fprintf,
> > tracing the userspace call and related kernel actions. Note that in
> > kernal event selector, we are allowed to use glob matching to match 
> > vfs_write
> > and vfs_writev together. For both of them we are allowed to check a 
> > internal
> > field of 'struct file'.
> >
> >   SEC(
> >   "target=/lib64/libc.so.6\n"
> >   "libcprintf=_IO_vfprintf_internal"
> >   )
> >   int libcprintf(void *ctx)
> >   {
> >       char fmt[] = "libc printf\n";
> >       bpf_trace_printk(fmt, sizeof(fmt));
> >       return 1;
> >   }
> >
> >   SEC("syswrite=vfs_write* file->f_mode")
> >   int vfswrite(void *ctx, int err, unsigned long f_mode)
> >   {
> >       char fmt[] = "vfs_write, f_mode=%lx\n";
> >       bpf_trace_printk(fmt, sizeof(fmt), f_mode);
> >
> >       if (f_mode & FMODE_READ)
> >           return 1;
> >       return 0;
> >   }
>
> looks great.
> Thank you for addressing comments so quickly.
> Pushed it to my tree to get buildbot coverage.
> It still should go via Arnaldo's tree when he has
> cycles to take a look at it.
> What do you plan to develop next?

Next target is to enable eBPF programs to fetch information from 
hardware PMU counters,
which I have discussed with you in previous mail, and including two 
separated works:

 1. Enable BPF programs read from PMU counter. We need a way to pass 
hardware PMU perf
    events from BPF object file to BPF program, and let it read from them.

 2. A way to enable BPF program output something to perf.data, together 
with the sample.

Now we are working on some prototype. Looks like both works are not very 
easy. I'd like
to share with you some ideas when prototype get stable.

Thank you.

> Thanks!


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/