Re: [PATCH V5 1/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling

[Alexei Starovoitov]

On 10/21/15 8:12 PM, Wangnan (F) wrote:
> On 2015/10/22 11:09, Alexei Starovoitov wrote:
> > On 10/21/15 6:56 PM, Wangnan (F) wrote:
> > > > One alternative solution I can image is to attach a BPF program
> > > > at sampling like kprobe, and return 0 if we don't want sampling
> > > > take action. Thought?
> > >
> > > Do you think attaching BPF programs to sampling is an acceptable idea?
> >
> > If you mean to extend 'filter' concept to sampling events?
> > So instead of soft_disable of non-local events, you'll attach bpf
> > program to sampling events and use map lookup to decide whether
> > to filter out or not such sampling event?
>
> Yes.
>
> > What pt_regs would be in such case?
>
> Sampling is based on interruption. We can use pt_reg captured by the IRQ
> handler,
> or we can simply pass NULL to those BPF program.

NULL is obviously not ok. Try to answer yourself 'why it's not'.
Clean implementation should add single 'if (..->prog)' to event sampling
critical path. Please don't rush it and think it through.
but the first thing first, please see my fix for bpf_perf_event_read:
http://patchwork.ozlabs.org/patch/534120/
and ack it if it makes sense.
we need to make sure existing stuff is solid, before going further.

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