[RFC PATCH v5 0/3] Make eBPF programs output data to perf

[RFC PATCH v5 0/3] Make eBPF programs output data to perf

[He Kuang]

Hi,

Previous patch v4 url:
http://thread.gmane.org/gmane.linux.kernel/1993353

This version we output bpf trace events in a hex array, the results
for three u64 integers in previous sample changed to this:

  dd 1042 [000] 1296.122951: bpf:bpf_output_data: 7a ca aa c6 2d 01 00
  00 95 87 ec ca 2d 01 00 00 1b bd 41 04 00 00 00 00

Users can interpret their own formats and get the result:

  last=0x12dc6aaca7a, cur=0x12dcaec8795, del=0x441bd1b

v3-v4:
 - Change u64 array in trace event to u8.
 - Remove misleading 'perf event' in subject.

Thank you.

He Kuang (3):
  tracing/events: Fix wrong sample output by storing array length
    instead of size
  tools lib traceevent: Add function to get dynamic arrays length
  bpf: Introduce function for outputing trace event data

 include/trace/events/bpf.h                         | 30 +++++++++++++
 include/trace/trace_events.h                       |  5 ++-
 include/uapi/linux/bpf.h                           |  7 +++
 kernel/trace/bpf_trace.c                           | 23 ++++++++++
 samples/bpf/bpf_helpers.h                          |  2 +
 tools/lib/traceevent/event-parse.c                 | 52 ++++++++++++++++++++++
 tools/lib/traceevent/event-parse.h                 |  1 +
 .../util/scripting-engines/trace-event-python.c    |  1 +
 8 files changed, 119 insertions(+), 2 deletions(-)
 create mode 100644 include/trace/events/bpf.h

-- 
1.8.5.2

[RFC PATCH v5 1/3] tracing/events: Fix wrong sample output by storing array length instead of size

[He Kuang]

The output result of trace_foo_bar event in traceevent samples is
wrong. This problem can be reproduced as following:

  (Build kernel with SAMPLE_TRACE_EVENTS=m)

  $ insmod trace-events-sample.ko

  $ echo 1 > /sys/kernel/debug/tracing/events/sample-trace/foo_bar/enable

  $ cat /sys/kernel/debug/tracing/trace

  event-sample-980 [000] ....  43.649559: foo_bar: foo hello 21 0x15
  BIT1|BIT3|0x10 {0x1,0x6f6f6e53,0xff007970,0xffffffff} Snoopy
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                 The array length is not right, should be {0x1}.
  (ffffffff,ffffffff)

  event-sample-980 [000] ....  44.653827: foo_bar: foo hello 22 0x16
  BIT2|BIT3|0x10
  {0x1,0x2,0x646e6147,0x666c61,0xffffffff,0xffffffff,0x750aeffe,0x7}
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                 The array length is not right, should be {0x1,0x2}.
  Gandalf (ffffffff,ffffffff)

The event defined in samples/trace_events/trace-events-sample.h uses
this helper function to output dynamic list:

   __print_array(__get_dynamic_array(list),
                 __get_dynamic_array_len(list),
                 sizeof(int))

Currently, __get_dynamic_array_len() returns the total size of the
array instead of the number of items by referencing the high 16 bits
of entry->data_loc_##item. The element size for calculating the number
of items can not be fetched by referencing fields from __entry, so
macro __get_dynamic_array_len can not return the expected value.

This patch stores array item number instead of the total size in
entry->__data_loc_##item, and makes __get_dynamic_array_len get the
right value directly. Because the function __get_bitmask() is affected
by this change, __bitmask_size is assigned to the array len by
multiplied bitmask type size.

After this patch:

  event-sample-993 [000] ....  692.348562: foo_bar: foo hello 201
  0xc9 BIT1|BIT4|0xc0 {0x1} Snoopy (ffffffff,ffffffff)
                      ^^^^^
                      Array length fixed.

  event-sample-993 [000] ....  693.349276: foo_bar: foo hello 202
  0xca BIT2|BIT4|0xc0 {0x1,0x2} Gandalf (ffffffff,ffffffff)
                      ^^^^^^^^^
                      Array length fixed.

Signed-off-by: He Kuang <hekuang@huawei.com>
---
 include/trace/trace_events.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/trace/trace_events.h b/include/trace/trace_events.h
index 43be3b0..5abe027 100644
--- a/include/trace/trace_events.h
+++ b/include/trace/trace_events.h
@@ -257,7 +257,8 @@ TRACE_MAKE_SYSTEM_STR();
 	({								\
 		void *__bitmask = __get_dynamic_array(field);		\
 		unsigned int __bitmask_size;				\
-		__bitmask_size = __get_dynamic_array_len(field);	\
+		__bitmask_size = (__get_dynamic_array_len(field) *	\
+				  sizeof(unsigned long));		\
 		trace_print_bitmask_seq(p, __bitmask, __bitmask_size);	\
 	})
 
@@ -453,7 +454,7 @@ trace_event_define_fields_##call(struct trace_event_call *event_call)	\
 	__item_length = (len) * sizeof(type);				\
 	__data_offsets->item = __data_size +				\
 			       offsetof(typeof(*entry), __data);	\
-	__data_offsets->item |= __item_length << 16;			\
+	__data_offsets->item |= (len) << 16;				\
 	__data_size += __item_length;
 
 #undef __string
-- 
1.8.5.2

[RFC PATCH v5 2/3] tools lib traceevent: Add function to get dynamic arrays length

[He Kuang]

To print a trace event with a dynamic array, __print_array(array, len,
element_size) requires the number of items in the array, which can be
got by the helper function __get_dynamic_array_len(), currently it is
not an available function in the function list in process_function().

Add new arg type PRINT_DYNAMIC_ARRAY_LEN which returns the array
length embedded in the __data_loc_##item field to eval_num_arg().

Signed-off-by: He Kuang <hekuang@huawei.com>
---
 tools/lib/traceevent/event-parse.c                 | 52 ++++++++++++++++++++++
 tools/lib/traceevent/event-parse.h                 |  1 +
 .../util/scripting-engines/trace-event-python.c    |  1 +
 3 files changed, 54 insertions(+)

diff --git a/tools/lib/traceevent/event-parse.c b/tools/lib/traceevent/event-parse.c
index cc25f05..55fc3b6c 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -783,6 +783,7 @@ static void free_arg(struct print_arg *arg)
 		free(arg->bitmask.bitmask);
 		break;
 	case PRINT_DYNAMIC_ARRAY:
+	case PRINT_DYNAMIC_ARRAY_LEN:
 		free(arg->dynarray.index);
 		break;
 	case PRINT_OP:
@@ -2655,6 +2656,42 @@ process_dynamic_array(struct event_format *event, struct print_arg *arg, char **
 }
 
 static enum event_type
+process_dynamic_array_len(struct event_format *event, struct print_arg *arg,
+			  char **tok)
+{
+	struct format_field *field;
+	enum event_type type;
+	char *token;
+
+	if (read_expect_type(EVENT_ITEM, &token) < 0)
+		goto out_free;
+
+	arg->type = PRINT_DYNAMIC_ARRAY_LEN;
+
+	/* Find the field */
+	field = pevent_find_field(event, token);
+	if (!field)
+		goto out_free;
+
+	arg->dynarray.field = field;
+	arg->dynarray.index = 0;
+
+	if (read_expected(EVENT_DELIM, ")") < 0)
+		goto out_err;
+
+	type = read_token(&token);
+	*tok = token;
+
+	return type;
+
+ out_free:
+	free_token(token);
+ out_err:
+	*tok = NULL;
+	return EVENT_ERROR;
+}
+
+static enum event_type
 process_paren(struct event_format *event, struct print_arg *arg, char **tok)
 {
 	struct print_arg *item_arg;
@@ -2901,6 +2938,10 @@ process_function(struct event_format *event, struct print_arg *arg,
 		free_token(token);
 		return process_dynamic_array(event, arg, tok);
 	}
+	if (strcmp(token, "__get_dynamic_array_len") == 0) {
+		free_token(token);
+		return process_dynamic_array_len(event, arg, tok);
+	}
 
 	func = find_func_handler(event->pevent, token);
 	if (func) {
@@ -3581,6 +3622,17 @@ eval_num_arg(void *data, int size, struct event_format *event, struct print_arg
 			goto out_warning_op;
 		}
 		break;
+	case PRINT_DYNAMIC_ARRAY_LEN:
+		offset = pevent_read_number(pevent,
+					    data + arg->dynarray.field->offset,
+					    arg->dynarray.field->size);
+		/*
+		 * The actual length of the dynamic array is stored
+		 * in the top half of the field, and the offset
+		 * is in the bottom half of the 32 bit field.
+		 */
+		val = (unsigned long long)(offset >> 16);
+		break;
 	case PRINT_DYNAMIC_ARRAY:
 		/* Without [], we pass the address to the dynamic data */
 		offset = pevent_read_number(pevent,
diff --git a/tools/lib/traceevent/event-parse.h b/tools/lib/traceevent/event-parse.h
index 063b197..94543aa 100644
--- a/tools/lib/traceevent/event-parse.h
+++ b/tools/lib/traceevent/event-parse.h
@@ -294,6 +294,7 @@ enum print_arg_type {
 	PRINT_OP,
 	PRINT_FUNC,
 	PRINT_BITMASK,
+	PRINT_DYNAMIC_ARRAY_LEN,
 };
 
 struct print_arg {
diff --git a/tools/perf/util/scripting-engines/trace-event-python.c b/tools/perf/util/scripting-engines/trace-event-python.c
index ace2484..d309341 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -253,6 +253,7 @@ static void define_event_symbols(struct event_format *event,
 	case PRINT_DYNAMIC_ARRAY:
 	case PRINT_FUNC:
 	case PRINT_BITMASK:
+	case PRINT_DYNAMIC_ARRAY_LEN:
 		/* we should warn... */
 		return;
 	}
-- 
1.8.5.2

Re: [RFC PATCH v5 2/3] tools lib traceevent: Add function to get dynamic arrays length

[Wangnan (F)]

On 2015/7/14 9:59, He Kuang wrote:
> To print a trace event with a dynamic array, __print_array(array, len,
> element_size) requires the number of items in the array, which can be
> got by the helper function __get_dynamic_array_len(), currently it is
> not an available function in the function list in process_function().
>
> Add new arg type PRINT_DYNAMIC_ARRAY_LEN which returns the array
> length embedded in the __data_loc_##item field to eval_num_arg().
>
> Signed-off-by: He Kuang <hekuang@huawei.com>
> ---
>   tools/lib/traceevent/event-parse.c                 | 52 ++++++++++++++++++++++
>   tools/lib/traceevent/event-parse.h                 |  1 +
>   .../util/scripting-engines/trace-event-python.c    |  1 +
>   3 files changed, 54 insertions(+)
>
> diff --git a/tools/lib/traceevent/event-parse.c b/tools/lib/traceevent/event-parse.c
> index cc25f05..55fc3b6c 100644
> --- a/tools/lib/traceevent/event-parse.c
> +++ b/tools/lib/traceevent/event-parse.c
> @@ -783,6 +783,7 @@ static void free_arg(struct print_arg *arg)
>   		free(arg->bitmask.bitmask);
>   		break;
>   	case PRINT_DYNAMIC_ARRAY:
> +	case PRINT_DYNAMIC_ARRAY_LEN:
>   		free(arg->dynarray.index);
>   		break;
>   	case PRINT_OP:
> @@ -2655,6 +2656,42 @@ process_dynamic_array(struct event_format *event, struct print_arg *arg, char **
>   }
>   
>   static enum event_type
> +process_dynamic_array_len(struct event_format *event, struct print_arg *arg,
> +			  char **tok)
> +{
> +	struct format_field *field;
> +	enum event_type type;
> +	char *token;
> +
> +	if (read_expect_type(EVENT_ITEM, &token) < 0)
> +		goto out_free;
> +
> +	arg->type = PRINT_DYNAMIC_ARRAY_LEN;
> +
> +	/* Find the field */
> +	field = pevent_find_field(event, token);
> +	if (!field)
> +		goto out_free;
> +
> +	arg->dynarray.field = field;
> +	arg->dynarray.index = 0;
> +
> +	if (read_expected(EVENT_DELIM, ")") < 0)
> +		goto out_err;
> +
> +	type = read_token(&token);
> +	*tok = token;
> +
> +	return type;
> +
> + out_free:
> +	free_token(token);
> + out_err:
> +	*tok = NULL;
> +	return EVENT_ERROR;
> +}
> +
> +static enum event_type
>   process_paren(struct event_format *event, struct print_arg *arg, char **tok)
>   {
>   	struct print_arg *item_arg;
> @@ -2901,6 +2938,10 @@ process_function(struct event_format *event, struct print_arg *arg,
>   		free_token(token);
>   		return process_dynamic_array(event, arg, tok);
>   	}
> +	if (strcmp(token, "__get_dynamic_array_len") == 0) {
> +		free_token(token);
> +		return process_dynamic_array_len(event, arg, tok);
> +	}
>   
>   	func = find_func_handler(event->pevent, token);
>   	if (func) {
> @@ -3581,6 +3622,17 @@ eval_num_arg(void *data, int size, struct event_format *event, struct print_arg
>   			goto out_warning_op;
>   		}
>   		break;
> +	case PRINT_DYNAMIC_ARRAY_LEN:
> +		offset = pevent_read_number(pevent,
> +					    data + arg->dynarray.field->offset,
> +					    arg->dynarray.field->size);
> +		/*
> +		 * The actual length of the dynamic array is stored
> +		 * in the top half of the field, and the offset
> +		 * is in the bottom half of the 32 bit field.
> +		 */
> +		val = (unsigned long long)(offset >> 16);
> +		break;
>   	case PRINT_DYNAMIC_ARRAY:
>   		/* Without [], we pass the address to the dynamic data */
>   		offset = pevent_read_number(pevent,
> diff --git a/tools/lib/traceevent/event-parse.h b/tools/lib/traceevent/event-parse.h
> index 063b197..94543aa 100644
> --- a/tools/lib/traceevent/event-parse.h
> +++ b/tools/lib/traceevent/event-parse.h
> @@ -294,6 +294,7 @@ enum print_arg_type {
>   	PRINT_OP,
>   	PRINT_FUNC,
>   	PRINT_BITMASK,
> +	PRINT_DYNAMIC_ARRAY_LEN,
>   };
>   
>   struct print_arg {
> diff --git a/tools/perf/util/scripting-engines/trace-event-python.c b/tools/perf/util/scripting-engines/trace-event-python.c
> index ace2484..d309341 100644
> --- a/tools/perf/util/scripting-engines/trace-event-python.c
> +++ b/tools/perf/util/scripting-engines/trace-event-python.c
> @@ -253,6 +253,7 @@ static void define_event_symbols(struct event_format *event,
>   	case PRINT_DYNAMIC_ARRAY:
>   	case PRINT_FUNC:
>   	case PRINT_BITMASK:
> +	case PRINT_DYNAMIC_ARRAY_LEN:

Here is a small problem in this patch that, it only updates 
trace-event-python.c, leaves
trace-event-perf.c unchanged. If CONFIG_LIBPERL is on, a compiling error 
will raise.

I fixed this in my own git repository.

Steven, could you please cherry-pick this one instead?

https://github.com/WangNan0/linux/commit/951d78339e8c7819e9a1a9faeaf15e2c0b1aaa10

Note that the author field of it is still He Kuang.

Thank you.

>   		/* we should warn... */
>   		return;
>   	}

Re: [RFC PATCH v5 2/3] tools lib traceevent: Add function to get dynamic arrays length

[Steven Rostedt]

Is this dependent on patch 1? Because I'm not sure that's going to be
the ending fix.


On Fri, 17 Jul 2015 11:36:54 +0800
"Wangnan (F)" <wangnan0@huawei.com> wrote:
 
> Here is a small problem in this patch that, it only updates 
> trace-event-python.c, leaves
> trace-event-perf.c unchanged. If CONFIG_LIBPERL is on, a compiling error 
> will raise.
> 
> I fixed this in my own git repository.
> 
> Steven, could you please cherry-pick this one instead?
> 
> https://github.com/WangNan0/linux/commit/951d78339e8c7819e9a1a9faeaf15e2c0b1aaa10

Please repost a proper patch to the mailing list.

Also, Arnaldo is the one that pulls in changes to the
tools/lib/traceevent code. But I would need to ack it first.

-- Steve

> 
> Note that the author field of it is still He Kuang.
> 
> Thank you.
> 
> >   		/* we should warn... */
> >   		return;
> >   	}
> 

Re: [RFC PATCH v5 2/3] tools lib traceevent: Add function to get dynamic arrays length

[pi3orama]

发自我的 iPhone

> 在 2015年7月17日，下午10:36，Steven Rostedt <rostedt@goodmis.org> 写道：
> 
> 
> Is this dependent on patch 1? Because I'm not sure that's going to be
> the ending fix.
> 
> 
> On Fri, 17 Jul 2015 11:36:54 +0800
> "Wangnan (F)" <wangnan0@huawei.com> wrote:
> 
>> Here is a small problem in this patch that, it only updates 
>> trace-event-python.c, leaves
>> trace-event-perf.c unchanged. If CONFIG_LIBPERL is on, a compiling error 
>> will raise.
>> 
>> I fixed this in my own git repository.
>> 
>> Steven, could you please cherry-pick this one instead?
>> 
>> https://github.com/WangNan0/linux/commit/951d78339e8c7819e9a1a9faeaf15e2c0b1aaa10
> 
> Please repost a proper patch to the mailing list.
> 
> Also, Arnaldo is the one that pulls in changes to the
> tools/lib/traceevent code. But I would need to ack it first.
> 

I'll wait for your conclusion on patch 1, and let He Kuang to repost it if this patch is still required.

Thanks.

> -- Steve
> 
>> 
>> Note that the author field of it is still He Kuang.
>> 
>> Thank you.
>> 
>>>          /* we should warn... */
>>>          return;
>>>      }
> 

[RFC PATCH v5 3/3] bpf: Introduce function for outputing trace event data

[He Kuang]

There're scenarios that we need an eBPF program to record not only
kprobe point args, but also the PMU counters, time latencies or the
number of cache misses between two probe points and other information
when the probe point is entered.

This patch adds a new trace event to establish infrastruction for bpf to
output data to perf. Userspace perf tools can detect and use this event
as using the existing tracepoint events.

New bpf trace event entry in debugfs:

     /sys/kernel/debug/tracing/events/bpf/bpf_output_data

Userspace perf tools detect the new tracepoint event as:

     bpf:bpf_output_data                          [Tracepoint event]

Data in ring-buffer of perf events added to this event will be polled
out, sample types and other attributes can be adjusted to those events
directly without touching the original kprobe events.

The bpf helper function gives eBPF program ability to output data as
perf sample event. This helper simple call the new trace event and
userspace perf tools can record the BPF ftrace event to collect those
records.

Signed-off-by: He Kuang <hekuang@huawei.com>
---
 include/trace/events/bpf.h | 30 ++++++++++++++++++++++++++++++
 include/uapi/linux/bpf.h   |  7 +++++++
 kernel/trace/bpf_trace.c   | 23 +++++++++++++++++++++++
 samples/bpf/bpf_helpers.h  |  2 ++
 4 files changed, 62 insertions(+)
 create mode 100644 include/trace/events/bpf.h

diff --git a/include/trace/events/bpf.h b/include/trace/events/bpf.h
new file mode 100644
index 0000000..82ace8a
--- /dev/null
+++ b/include/trace/events/bpf.h
@@ -0,0 +1,30 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM bpf
+
+#if !defined(_TRACE_BPF_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_BPF_H
+
+#include <linux/tracepoint.h>
+
+TRACE_EVENT(bpf_output_data,
+
+	TP_PROTO(void *src, int size),
+
+	TP_ARGS(src, size),
+
+	TP_STRUCT__entry(
+		__dynamic_array(u8,		buf,		size)
+	),
+
+	TP_fast_assign(
+		memcpy(__get_dynamic_array(buf), src, size);
+	),
+
+	TP_printk("%s", __print_hex(__get_dynamic_array(buf),
+				    __get_dynamic_array_len(buf)))
+);
+
+#endif /* _TRACE_BPF_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 29ef6f9..5068ab1 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -249,6 +249,13 @@ enum bpf_func_id {
 	 * Return: 0 on success
 	 */
 	BPF_FUNC_get_current_comm,
+
+	/**
+	 * int bpf_output_trace_data(void *src, int size)
+	 * Return: 0 on success
+	 */
+	BPF_FUNC_output_trace_data,
+
 	__BPF_FUNC_MAX_ID,
 };
 
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 88a041a..219f670 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -11,7 +11,10 @@
 #include <linux/filter.h>
 #include <linux/uaccess.h>
 #include <linux/ctype.h>
+
 #include "trace.h"
+#define CREATE_TRACE_POINTS
+#include <trace/events/bpf.h>
 
 static DEFINE_PER_CPU(int, bpf_prog_active);
 
@@ -79,6 +82,24 @@ static const struct bpf_func_proto bpf_probe_read_proto = {
 	.arg3_type	= ARG_ANYTHING,
 };
 
+static u64 bpf_output_trace_data(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
+{
+	void *src = (void *) (long) r1;
+	int size = (int) r2;
+
+	trace_bpf_output_data(src, size);
+
+	return 0;
+}
+
+static const struct bpf_func_proto bpf_output_trace_data_proto = {
+	.func		= bpf_output_trace_data,
+	.gpl_only	= true,
+	.ret_type	= RET_INTEGER,
+	.arg1_type	= ARG_PTR_TO_STACK,
+	.arg2_type	= ARG_CONST_STACK_SIZE,
+};
+
 /*
  * limited trace_printk()
  * only %d %u %x %ld %lu %lx %lld %llu %llx %p conversion specifiers allowed
@@ -169,6 +190,8 @@ static const struct bpf_func_proto *kprobe_prog_func_proto(enum bpf_func_id func
 		return &bpf_map_delete_elem_proto;
 	case BPF_FUNC_probe_read:
 		return &bpf_probe_read_proto;
+	case BPF_FUNC_output_trace_data:
+		return &bpf_output_trace_data_proto;
 	case BPF_FUNC_ktime_get_ns:
 		return &bpf_ktime_get_ns_proto;
 	case BPF_FUNC_tail_call:
diff --git a/samples/bpf/bpf_helpers.h b/samples/bpf/bpf_helpers.h
index bdf1c16..0aeaebe 100644
--- a/samples/bpf/bpf_helpers.h
+++ b/samples/bpf/bpf_helpers.h
@@ -59,5 +59,7 @@ static int (*bpf_l3_csum_replace)(void *ctx, int off, int from, int to, int flag
 	(void *) BPF_FUNC_l3_csum_replace;
 static int (*bpf_l4_csum_replace)(void *ctx, int off, int from, int to, int flags) =
 	(void *) BPF_FUNC_l4_csum_replace;
+static int (*bpf_output_trace_data)(void *src, int size) =
+	(void *) BPF_FUNC_output_trace_data;
 
 #endif
-- 
1.8.5.2

Re: [RFC PATCH v5 3/3] bpf: Introduce function for outputing trace event data

[Alexei Starovoitov]

On 7/13/15 6:59 PM, He Kuang wrote:
> There're scenarios that we need an eBPF program to record not only
> kprobe point args, but also the PMU counters, time latencies or the
> number of cache misses between two probe points and other information
> when the probe point is entered.
>
> This patch adds a new trace event to establish infrastruction for bpf to
> output data to perf. Userspace perf tools can detect and use this event
> as using the existing tracepoint events.
>
> New bpf trace event entry in debugfs:
>
>       /sys/kernel/debug/tracing/events/bpf/bpf_output_data
>
> Userspace perf tools detect the new tracepoint event as:
>
>       bpf:bpf_output_data                          [Tracepoint event]
>
> Data in ring-buffer of perf events added to this event will be polled
> out, sample types and other attributes can be adjusted to those events
> directly without touching the original kprobe events.
>
> The bpf helper function gives eBPF program ability to output data as
> perf sample event. This helper simple call the new trace event and
> userspace perf tools can record the BPF ftrace event to collect those
> records.
>
> Signed-off-by: He Kuang<hekuang@huawei.com>

Looks good to me.
Acked-by: Alexei Starovoitov <ast@plumgrid.com>

Re: [RFC PATCH v5 0/3] Make eBPF programs output data to perf

[Alexei Starovoitov]

On 7/13/15 6:59 PM, He Kuang wrote:
> This version we output bpf trace events in a hex array, the results
> for three u64 integers in previous sample changed to this:
>
>    dd 1042 [000] 1296.122951: bpf:bpf_output_data: 7a ca aa c6 2d 01 00
>    00 95 87 ec ca 2d 01 00 00 1b bd 41 04 00 00 00 00

typo in the above. It's not 3 u64 integers, but variable number of u8.

Whole thing looks good.
I've acked patch 3.
Hopefully Steven can review patches 1 and 2.

Re: [RFC PATCH v5 0/3] Make eBPF programs output data to perf

[Steven Rostedt]

On Mon, 13 Jul 2015 20:10:29 -0700
Alexei Starovoitov <ast@plumgrid.com> wrote:

> On 7/13/15 6:59 PM, He Kuang wrote:
> > This version we output bpf trace events in a hex array, the results
> > for three u64 integers in previous sample changed to this:
> >
> >    dd 1042 [000] 1296.122951: bpf:bpf_output_data: 7a ca aa c6 2d 01 00
> >    00 95 87 ec ca 2d 01 00 00 1b bd 41 04 00 00 00 00
> 
> typo in the above. It's not 3 u64 integers, but variable number of u8.
> 
> Whole thing looks good.
> I've acked patch 3.
> Hopefully Steven can review patches 1 and 2.

I'll try to get around to it ;-)

-- Steve

Re: [RFC PATCH v5 0/3] Make eBPF programs output data to perf

[He Kuang]

On 2015/7/14 21:35, Steven Rostedt wrote:
> On Mon, 13 Jul 2015 20:10:29 -0700
> Alexei Starovoitov <ast@plumgrid.com> wrote:
>
>> On 7/13/15 6:59 PM, He Kuang wrote:
>>> This version we output bpf trace events in a hex array, the results
>>> for three u64 integers in previous sample changed to this:
>>>
>>>     dd 1042 [000] 1296.122951: bpf:bpf_output_data: 7a ca aa c6 2d 01 00
>>>     00 95 87 ec ca 2d 01 00 00 1b bd 41 04 00 00 00 00
>>
>> typo in the above. It's not 3 u64 integers, but variable number of u8.
>>
>> Whole thing looks good.
>> I've acked patch 3.
>> Hopefully Steven can review patches 1 and 2.
>
> I'll try to get around to it ;-)
>
> -- Steve
>

Awaiting your reply ;-)

Thank you.

Re: [RFC PATCH v5 0/3] Make eBPF programs output data to perf

[Steven Rostedt]

On Fri, 17 Jul 2015 10:31:15 +0800
He Kuang <hekuang@huawei.com> wrote:

> Awaiting your reply ;-)

There's still a few more patches I have to look at first. Hopefully
I'll get to these tomorrow.

-- Steve

Re: [RFC PATCH v5 0/3] Make eBPF programs output data to perf

[Wangnan (F)]

On 2015/7/17 10:31, He Kuang wrote:
>
> On 2015/7/14 21:35, Steven Rostedt wrote:
>> On Mon, 13 Jul 2015 20:10:29 -0700
>> Alexei Starovoitov <ast@plumgrid.com> wrote:
>>
>>> On 7/13/15 6:59 PM, He Kuang wrote:
>>>> This version we output bpf trace events in a hex array, the results
>>>> for three u64 integers in previous sample changed to this:
>>>>
>>>>     dd 1042 [000] 1296.122951: bpf:bpf_output_data: 7a ca aa c6 2d 
>>>> 01 00
>>>>     00 95 87 ec ca 2d 01 00 00 1b bd 41 04 00 00 00 00
>>>
>>> typo in the above. It's not 3 u64 integers, but variable number of u8.
>>>
>>> Whole thing looks good.
>>> I've acked patch 3.
>>> Hopefully Steven can review patches 1 and 2.
>>
>> I'll try to get around to it ;-)
>>
>> -- Steve
>>
>
> Awaiting your reply ;-)
>
> Thank you.
>

Just for your information:

I collected this 3 patches in my own git tree:

https://github.com/WangNan0/linux ebpf

And I'll collect other patches made by our team there.

Thank you.