Re: [PATCH RFC net-next 11/14] tracing: allow eBPF programs to be attached to events

[Namhyung Kim <namhyung-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Fri, 27 Jun 2014 17:06:03 -0700, Alexei Starovoitov wrote:
> User interface:
> cat bpf_123 > /sys/kernel/debug/tracing/__event__/filter
>
> where 123 is an id of the eBPF program priorly loaded.
> __event__ is static tracepoint event.
> (kprobe events will be supported in the future patches)
>
> eBPF programs can call in-kernel helper functions to:
> - lookup/update/delete elements in maps
> - memcmp
> - trace_printk

ISTR Steve doesn't like to use trace_printk() (at least for production
kernels) anymore.  And I'm not sure it'd work if there's no existing
trace_printk() on a system.

> - load_pointer
> - dump_stack


[SNIP]
> @@ -634,6 +635,15 @@ ftrace_raw_event_##call(void *__data, proto)				\
>  	if (ftrace_trigger_soft_disabled(ftrace_file))			\
>  		return;							\
>  									\
> +	if (unlikely(ftrace_file->flags & FTRACE_EVENT_FL_FILTERED) &&	\
> +	    unlikely(ftrace_file->event_call->flags & TRACE_EVENT_FL_BPF)) { \
> +		struct bpf_context __ctx;				\
> +									\
> +		populate_bpf_context(&__ctx, args, 0, 0, 0, 0, 0);	\
> +		trace_filter_call_bpf(ftrace_file->filter, &__ctx);	\
> +		return;							\
> +	}								\
> +									\

Hmm..  But it seems the eBPF prog is not a filter - it'd always drop the
event.  And I think it's better to use a recorded entry rather then args
as a bpf_context so that tools like perf can manipulate it at compile
time based on the event format.

Thanks,
Namhyung


>  	__data_size = ftrace_get_offsets_##call(&__data_offsets, args); \
>  									\
>  	entry = ftrace_event_buffer_reserve(&fbuffer, ftrace_file,	\