Re: [RFC PATCH bpf-next] libbpf: make bpf_object__open default to UNSPEC

2018-11-23 Thread Wangnan (F)
On 2018/11/23 5:52, Daniel Borkmann wrote: > [ +Wang ] > > On 11/22/2018 07:03 AM, Nikita V. Shirokov wrote: >> currently by default libbpf's bpf_object__open requires >> bpf's program to specify version in a code because of two things: >> 1) default prog type is set to KPROBE >> 2) KPROBE

Re: [PATCH v2 net-next 3/6] tools/lib/bpf: expose bpf_program__set_type()

2017-03-31 Thread Wangnan (F)
On 2017/4/1 11:18, Alexei Starovoitov wrote: On 3/31/17 7:29 PM, Wangnan (F) wrote: On 2017/3/31 12:45, Alexei Starovoitov wrote: expose bpf_program__set_type() to set program type Signed-off-by: Alexei Starovoitov <a...@kernel.org> Acked-by: Daniel Borkmann <dan...@iogearbox.n

Re: [PATCH v2 net-next 3/6] tools/lib/bpf: expose bpf_program__set_type()

2017-03-31 Thread Wangnan (F)
On 2017/3/31 12:45, Alexei Starovoitov wrote: expose bpf_program__set_type() to set program type Signed-off-by: Alexei Starovoitov Acked-by: Daniel Borkmann Acked-by: Martin KaFai Lau --- tools/lib/bpf/libbpf.c | 3 +--

Re: [PATCH v2 net-next 3/6] tools/lib/bpf: expose bpf_program__set_type()

2017-03-31 Thread Wangnan (F)
Hi Alexei, Please see the patch I sent. Since we export bpf_program__set_type(), bpf_program__set_xxx() should be built based on it. Thank you. On 2017/3/31 12:45, Alexei Starovoitov wrote: expose bpf_program__set_type() to set program type Signed-off-by: Alexei Starovoitov

Re: [PATCH v2 net-next 2/6] tools/lib/bpf: add support for BPF_PROG_TEST_RUN command

2017-03-31 Thread Wangnan (F)
On 2017/3/31 12:45, Alexei Starovoitov wrote: add support for BPF_PROG_TEST_RUN command to libbpf.a Signed-off-by: Alexei Starovoitov Acked-by: Daniel Borkmann Acked-by: Martin KaFai Lau Acked-by: Wang Nan ---

Re: [PATCH net-next 1/6] bpf: introduce BPF_PROG_TEST_RUN command

2017-03-30 Thread Wangnan (F)
On 2017/3/31 11:24, Alexei Starovoitov wrote: On 3/30/17 8:12 PM, Wangnan (F) wrote: On 2017/3/31 10:57, Alexei Starovoitov wrote: On 3/30/17 7:53 PM, Wangnan (F) wrote: I suggest using a CONFIG option to enable/disable code in test_run.o to reduce attack plane. attack plane? what

Re: [PATCH net-next 2/6] tools/lib/bpf: add support for BPF_PROG_TEST_RUN command

2017-03-30 Thread Wangnan (F)
On 2017/3/31 9:31, Alexei Starovoitov wrote: add support for BPF_PROG_TEST_RUN command to libbpf.a Signed-off-by: Alexei Starovoitov Acked-by: Daniel Borkmann Acked-by: Martin KaFai Lau --- tools/include/uapi/linux/bpf.h | 24

Re: [PATCH net-next 1/6] bpf: introduce BPF_PROG_TEST_RUN command

2017-03-30 Thread Wangnan (F)
On 2017/3/31 10:57, Alexei Starovoitov wrote: On 3/30/17 7:53 PM, Wangnan (F) wrote: I suggest using a CONFIG option to enable/disable code in test_run.o to reduce attack plane. attack plane? what attack do you see and how config helps? I think all testing features are not required

Re: [PATCH net-next 1/6] bpf: introduce BPF_PROG_TEST_RUN command

2017-03-30 Thread Wangnan (F)
On 2017/3/31 9:31, Alexei Starovoitov wrote: development and testing of networking bpf programs is quite cumbersome. Despite availability of user space bpf interpreters the kernel is the ultimate authority and execution environment. Current test frameworks for TC include creation of netns,

Re: [PATCH net-next 4/6] tools/lib/bpf: expose bpf_program__set_type()

2017-03-30 Thread Wangnan (F)
On 2017/3/31 10:37, Alexei Starovoitov wrote: On 3/30/17 7:33 PM, Wangnan (F) wrote: +void bpf_program__set_type(struct bpf_program *prog, enum bpf_prog_type type); This makes libbpf.h depend on uapi/linux/bpf.h (because of enum bpf_prog_type), which is not always available. What about

Re: [PATCH net-next 4/6] tools/lib/bpf: expose bpf_program__set_type()

2017-03-30 Thread Wangnan (F)
On 2017/3/31 9:31, Alexei Starovoitov wrote: expose bpf_program__set_type() to set program type Signed-off-by: Alexei Starovoitov Acked-by: Daniel Borkmann Acked-by: Martin KaFai Lau --- tools/lib/bpf/libbpf.c | 3 +--

Re: [PATCH net-next v1] bpf: Remove redundant ifdef

2017-02-14 Thread Wangnan (F)
On 2017/2/15 1:07, David Miller wrote: From: "Wangnan (F)" <wangn...@huawei.com> Date: Mon, 13 Feb 2017 09:53:49 +0800 On 2017/2/12 3:37, Mickaël Salaün wrote: Remove a useless ifdef __NR_bpf as requested by Wang Nan. Inline one-line static functions as it was in th

Re: [PATCH net-next v1] bpf: Remove redundant ifdef

2017-02-12 Thread Wangnan (F)
On 2017/2/12 3:37, Mickaël Salaün wrote: Remove a useless ifdef __NR_bpf as requested by Wang Nan. Inline one-line static functions as it was in the bpf_sys.h file. Signed-off-by: Mickaël Salaün Cc: Alexei Starovoitov Cc: Daniel Borkmann

Re: [PATCH v4 0/3] Miscellaneous fixes for BPF (perf tree)

2017-02-12 Thread Wangnan (F)
On 2017/2/9 4:27, Mickaël Salaün wrote: This series brings some fixes and small improvements to the BPF samples. This is intended for the perf tree and apply on 7a5980f9c006 ("tools lib bpf: Add missing header to the library"). Changes since v3: * remove applied patch 1/5 * remove patch 2/5

Re: [PATCH net-next v5 04/11] bpf: Use bpf_load_program() from the library

2017-02-09 Thread Wangnan (F)
On 2017/2/10 10:25, Wangnan (F) wrote: On 2017/2/10 7:21, Mickaël Salaün wrote: Replace bpf_prog_load() with bpf_load_program() calls. Signed-off-by: Mickaël Salaün <m...@digikod.net> Cc: Alexei Starovoitov <a...@fb.com> Cc: Daniel Borkmann <dan...@iogearbox.net>

Re: [PATCH net-next v5 10/11] bpf: Remove bpf_sys.h from selftests

2017-02-09 Thread Wangnan (F)
On 2017/2/10 7:21, Mickaël Salaün wrote: Add require dependency headers. Signed-off-by: Mickaël Salaün Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Shuah Khan --- tools/lib/bpf/bpf.c | 6

Re: [PATCH net-next v5 04/11] bpf: Use bpf_load_program() from the library

2017-02-09 Thread Wangnan (F)
On 2017/2/10 7:21, Mickaël Salaün wrote: Replace bpf_prog_load() with bpf_load_program() calls. Signed-off-by: Mickaël Salaün Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Shuah Khan --- tools/lib/bpf/bpf.c

Re: [PATCH v2 1/5] bpf: Add missing header to the library

2017-02-07 Thread Wangnan (F)
Please add me into the cc list of all of the 5 patches. Thank you. On 2017/2/7 4:40, Mickaël Salaün wrote: Include stddef.h to define size_t. Signed-off-by: Mickaël Salaün Cc: Alexei Starovoitov Cc: Arnaldo Carvalho de Melo Cc: Daniel

Re: [PATCH v3 1/5] bpf: Add missing header to the library

2017-02-07 Thread Wangnan (F)
On 2017/2/8 4:56, Mickaël Salaün wrote: Include stddef.h to define size_t. Signed-off-by: Mickaël Salaün Cc: Alexei Starovoitov Cc: Arnaldo Carvalho de Melo Cc: Daniel Borkmann Cc: Wang Nan ---

Re: [PATCH v3 2/5] bpf: Simplify bpf_load_program() error handling in the library

2017-02-07 Thread Wangnan (F)
On 2017/2/8 4:56, Mickaël Salaün wrote: Do not call a second time bpf(2) when a program load failed. BPF_PROG_LOAD should success most of the time. Setting log_level to 0 by default and require log buffer when failure can make it faster in normal case. Thank you. Signed-off-by: Mickaël

Re: [PATCHv2 perf/core 5/7] tools lib bpf: Add bpf_program__pin()

2017-01-24 Thread Wangnan (F)
On 2017/1/25 9:16, Joe Stringer wrote: On 24 January 2017 at 17:06, Wangnan (F) <wangn...@huawei.com> wrote: On 2017/1/25 9:04, Wangnan (F) wrote: On 2017/1/23 9:11, Joe Stringer wrote: Add a new API to pin a BPF program to the filesystem. The user can specify the path full path

Re: [PATCHv2 perf/core 5/7] tools lib bpf: Add bpf_program__pin()

2017-01-24 Thread Wangnan (F)
On 2017/1/25 9:04, Wangnan (F) wrote: On 2017/1/23 9:11, Joe Stringer wrote: Add a new API to pin a BPF program to the filesystem. The user can specify the path full path within a BPF filesystem to pin the program. Programs with multiple instances are pinned as 'foo', 'foo_1', 'foo_2

Re: [PATCHv2 perf/core 5/7] tools lib bpf: Add bpf_program__pin()

2017-01-24 Thread Wangnan (F)
On 2017/1/23 9:11, Joe Stringer wrote: Add a new API to pin a BPF program to the filesystem. The user can specify the path full path within a BPF filesystem to pin the program. Programs with multiple instances are pinned as 'foo', 'foo_1', 'foo_2', and so on. Signed-off-by: Joe Stringer

Re: [PATCHv3 perf/core 5/7] samples/bpf: Switch over to libbpf

2016-12-08 Thread Wangnan (F)
On 2016/12/9 13:04, Wangnan (F) wrote: On 2016/12/9 10:46, Joe Stringer wrote: [SNIP] diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile index 62d89d50fcbd..616bd55f3be8 100644 --- a/tools/lib/bpf/Makefile +++ b/tools/lib/bpf/Makefile @@ -149,6 +149,8 @@ CMD_TARGETS

Re: [PATCHv3 perf/core 5/7] samples/bpf: Switch over to libbpf

2016-12-08 Thread Wangnan (F)
On 2016/12/9 10:46, Joe Stringer wrote: Now that libbpf under tools/lib/bpf/* is synced with the version from samples/bpf, we can get rid most of the libbpf library here. Signed-off-by: Joe Stringer --- v3: First post. --- samples/bpf/Makefile | 60

Re: [PATCHv3 perf/core 3/7] tools lib bpf: Add flags to bpf_create_map()

2016-12-08 Thread Wangnan (F)
On 2016/12/9 10:46, Joe Stringer wrote: The map_flags argument to bpf_create_map() was previously not exposed. By exposing it, users can access flags such as whether or not to preallocate the map. Signed-off-by: Joe Stringer Please mention commit

Re: [PATCHv3 perf/core 2/7] tools lib bpf: use __u32 from linux/types.h

2016-12-08 Thread Wangnan (F)
On 2016/12/9 10:46, Joe Stringer wrote: Fixes the following issue when building without access to 'u32' type: ./tools/lib/bpf/bpf.h:27:23: error: unknown type name ‘u32’ Signed-off-by: Joe Stringer --- v3: Split from "tools lib bpf: Sync with samples/bpf/libbpf" ---

Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf

2016-11-16 Thread Wangnan (F)
On 2016/11/17 10:46, Joe Stringer wrote: On 16 November 2016 at 18:10, Wangnan (F) <wangn...@huawei.com> wrote: I'm also working on improving bpf.c. Please have a look at: https://lkml.org/lkml/2016/11/14/1078 Since bpf.c is simple, I think we can add more functions and fixes gra

Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf

2016-11-16 Thread Wangnan (F)
On 2016/11/17 10:46, Joe Stringer wrote: On 16 November 2016 at 18:10, Wangnan (F) <wangn...@huawei.com> wrote: I'm also working on improving bpf.c. Please have a look at: https://lkml.org/lkml/2016/11/14/1078 Since bpf.c is simple, I think we can add more functions and fixes gra

Re: [PATCHv2 perf/core 2/2] tools lib bpf: Sync with samples/bpf/libbpf

2016-11-16 Thread Wangnan (F)
I'm also working on improving bpf.c. Please have a look at: https://lkml.org/lkml/2016/11/14/1078 Since bpf.c is simple, I think we can add more functions and fixes gradually, instead of a full copy. See my inline comment below. On 2016/11/17 1:43, Joe Stringer wrote: Extend the tools/

Re: [PATCHv2 perf/core 1/2] tools lib bpf: Sync {tools,}/include/uapi/linux/bpf.h

2016-11-16 Thread Wangnan (F)
On 2016/11/17 1:43, Joe Stringer wrote: The tools version of this header is out of date; update it to the latest version from the kernel headers. Signed-off-by: Joe Stringer --- v2: No change. --- tools/include/uapi/linux/bpf.h | 51 ++

Re: [PATCH 7/8] tools lib bpf: fix maps resolution

2016-11-08 Thread Wangnan (F)
Hi Eric, During testing this patch I find a segfault, please see inline comment. In addition, since both the BPF map array and map names should be done after symbol table is collected, merging bpf_object__init_maps and bpf_object__init_maps_name would be a good practice, making code simpler.

Re: [PATCH 7/8] tools lib bpf: fix maps resolution

2016-11-07 Thread Wangnan (F)
Hi Eric, Are you still working in this patch set? Now I know why maps section is not a simple array from a patch set from Joe Stringer: https://www.mail-archive.com/netdev@vger.kernel.org/msg135088.html So I think this patch is really useful. Are you going to resend the whole patch set? If

Re: [PATCH 1/8] tools lib bpf: add error functions

2016-10-18 Thread Wangnan (F)
On 2016/10/19 6:52, Joe Stringer wrote: On 16 October 2016 at 14:18, Eric Leblond wrote: The include of err.h is not explicitely needed in exported functions and it was causing include conflict with some existing code due to redefining some macros. To fix this, let's have

Re: [PATCH 7/8] tools lib bpf: fix maps resolution

2016-10-16 Thread Wangnan (F)
On 2016/10/17 5:18, Eric Leblond wrote: It is not correct to assimilate the elf data of the maps section to an array of map definition. In fact the sizes differ. The offset provided in the symbol section has to be used instead. This patch fixes a bug causing a elf with two maps not to load

Re: [PATCH 5/8] tools lib bpf: add missing functions

2016-10-16 Thread Wangnan (F)
On 2016/10/17 5:18, Eric Leblond wrote: Some functions were missing in the library to be able to use it in the case where the userspace is handling the maps in kernel. The patch also renames functions to have a homogeneous naming convention. Signed-off-by: Eric Leblond ---

Re: [PATCH 6/8] tools lib bpf: improve warning

2016-10-16 Thread Wangnan (F)
On 2016/10/17 5:18, Eric Leblond wrote: Signed-off-by: Eric Leblond Please add some commit messages. Thank you. --- tools/lib/bpf/libbpf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c index

Re: [PATCH 4/8] tools lib bpf: export function to set type

2016-10-16 Thread Wangnan (F)
On 2016/10/17 5:18, Eric Leblond wrote: Current API was not allowing the user to set a type like socket filter. To avoid a setter function for each type, the patch simply exports a set function that takes the type in parameter. Signed-off-by: Eric Leblond ---

Re: [PATCH 3/8] tools: Sync tools/include/uapi/linux/bpf.h with the kernel

2016-10-16 Thread Wangnan (F)
On 2016/10/17 5:18, Eric Leblond wrote: Signed-off-by: Eric Leblond Commit message is required. Thank you. --- tools/include/uapi/linux/bpf.h | 52 ++ 1 file changed, 52 insertions(+) diff --git a/tools/include/uapi/linux/bpf.h

Re: [PATCH 1/8] tools lib bpf: add error functions

2016-10-16 Thread Wangnan (F)
On 2016/10/17 5:18, Eric Leblond wrote: The include of err.h is not explicitely needed in exported functions and it was causing include conflict with some existing code due to redefining some macros. To fix this, let's have error handling functions provided by the library. Furthermore this

Re: [PATCH net-next 2/2] tools lib bpf: export function to set type

2016-08-14 Thread Wangnan (F)
On 2016/8/13 20:17, Eric Leblond wrote: Current API was not allowing the user to set a type like socket filter. To avoid a setter function for each type, the patch simply exports a set function that takes the type in parameter. Signed-off-by: Eric Leblond ---

Re: [PATCH net-next 1/2] tools lib bpf: suppress useless include

2016-08-14 Thread Wangnan (F)
On 2016/8/13 20:17, Eric Leblond wrote: The include of err.h is not explicitely needed in exported functions and it was causing include conflict with some existing code due to redefining some macros. Signed-off-by: Eric Leblond --- tools/lib/bpf/libbpf.c | 1 +

Re: [PATCH net-next 0/2] libbpf: minor fix and API update

2016-08-14 Thread Wangnan (F)
I think you should cc linux-ker...@vger.kernel.org for code in tools/ . Thank you. On 2016/8/13 20:17, Eric Leblond wrote: Hello, Here's a small patchset on libbpf fixing two issues I've encountered when adding some eBPF related features to Suricata. Patchset statistics:

Re: [RFC PATCH net-next 0/4] perf tools: Support receiving output through BPF programs

2015-10-28 Thread Wangnan (F)
On 2015/10/28 18:55, Wang Nan wrote: Alexei provided a patchset to allow BPF programs output data to ring buffer using helper bpf_perf_event_output() [1]. and have been merged into net-next as commit a43eec304259a6c637f4014a6d4767159b6a3aa3 (bpf: introduce bpf_perf_event_output() helper).

Re: [PATCH v3 net-next] bpf: fix bpf_perf_event_read() helper

2015-10-26 Thread Wangnan (F)
On 2015/10/26 20:32, Peter Zijlstra wrote: On Sun, Oct 25, 2015 at 09:23:36AM -0700, Alexei Starovoitov wrote: bpf_perf_event_read() muxes of -EINVAL into return value, but it's non ambiguous to the program whether it got an error or real counter value. How can that be, the (u64)-EINVAL

Re: [PATCH net-next 2/3] bpf: introduce bpf_perf_event_output() helper

2015-10-25 Thread Wangnan (F)
On 2015/10/24 1:25, Alexei Starovoitov wrote: On 10/23/15 9:42 AM, Peter Zijlstra wrote: On Fri, Oct 23, 2015 at 08:02:00AM -0700, Alexei Starovoitov wrote: On 10/23/15 7:39 AM, Peter Zijlstra wrote: On Tue, Oct 20, 2015 at 08:02:34PM -0700, Alexei Starovoitov wrote: +static const struct

Re: [PATCH v2 net-next] bpf: fix bpf_perf_event_read() helper

2015-10-22 Thread Wangnan (F)
On 2015/10/22 14:21, Alexei Starovoitov wrote: On 10/21/15 10:31 PM, Wangnan (F) wrote: +if ((attr->type != PERF_TYPE_RAW && + !(attr->type == PERF_TYPE_SOFTWARE && + attr->config == PERF_COUNT_SW_BPF_OUTPUT) && +

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

2015-10-22 Thread Wangnan (F)
On 2015/10/22 15:39, Ingo Molnar wrote: * Wangnan (F) <wangn...@huawei.com> wrote: [SNIP] In summary, your either-or logic doesn't hold in BPF world. A BPF program can only access perf event in a highly restricted way. We don't allow it calling perf_event_read_local() across co

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

2015-10-22 Thread Wangnan (F)
On 2015/10/22 17:06, Peter Zijlstra wrote: On Wed, Oct 21, 2015 at 02:19:49PM -0700, Alexei Starovoitov wrote: Urgh, that's still horridly inconsistent. Can we please come up with a consistent interface to perf? My suggestion was to do ioctl(enable/disable) of events from userspace after

Re: [PATCH v2 net-next] bpf: fix bpf_perf_event_read() helper

2015-10-22 Thread Wangnan (F)
On 2015/10/22 6:58, Alexei Starovoitov wrote: [SNIP] diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c index e3cfe46b074f..75529cc94304 100644 --- a/kernel/bpf/arraymap.c +++ b/kernel/bpf/arraymap.c @@ -294,10 +294,11 @@ static void *perf_event_fd_array_get_ptr(struct bpf_map *map,

Re: [PATCH v3 net-next] bpf: fix bpf_perf_event_read() helper

2015-10-22 Thread Wangnan (F)
On 2015/10/23 8:10, Alexei Starovoitov wrote: Fix safety checks for bpf_perf_event_read(): - only non-inherited events can be added to perf_event_array map (do this check statically at map insertion time) - dynamically check that event is local and !pmu->count Otherwise buggy bpf program

Re: [PATCH v3 net-next] bpf: fix bpf_perf_event_read() helper

2015-10-22 Thread Wangnan (F)
On 2015/10/23 8:10, Alexei Starovoitov wrote: Fix safety checks for bpf_perf_event_read(): - only non-inherited events can be added to perf_event_array map (do this check statically at map insertion time) - dynamically check that event is local and !pmu->count Otherwise buggy bpf program

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

2015-10-21 Thread Wangnan (F)
On 2015/10/21 20:17, Peter Zijlstra wrote: On Wed, Oct 21, 2015 at 07:49:34PM +0800, Wangnan (F) wrote: If our task is sampling cycle events during a function is running, and if two cores start that function overlap: Time: ...A Core 0: sys_write

Re: [PATCH v2 net-next] bpf: fix bpf_perf_event_read() helper

2015-10-21 Thread Wangnan (F)
After applying this patch I'm unable to use perf passing perf_event again like this: # perf record -a -e evt=cycles -e ./test_config_map.c/maps.pmu_map.event=evt/ --exclude-perf ls With -v it output: ... adding perf_bpf_probe:func_write adding perf_bpf_probe:func_write to 0x367d6a0 add bpf

Re: [PATCH v2 net-next] bpf: fix bpf_perf_event_read() helper

2015-10-21 Thread Wangnan (F)
On 2015/10/22 6:58, Alexei Starovoitov wrote: Fix safety checks for bpf_perf_event_read(): - only non-inherited events can be added to perf_event_array map (do this check statically at map insertion time) - dynamically check that event is local and !pmu->count Otherwise buggy bpf program

Re: [PATCH v2 net-next] bpf: fix bpf_perf_event_read() helper

2015-10-21 Thread Wangnan (F)
On 2015/10/22 13:00, Alexei Starovoitov wrote: On 10/21/15 9:49 PM, Wangnan (F) wrote: After applying this patch I'm unable to use perf passing perf_event again like this: please do not top post and trim your replies. # perf record -a -e evt=cycles -e ./test_config_map.c

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

2015-10-21 Thread Wangnan (F)
Hi Alexei, On 2015/10/21 21:42, 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? Thank you

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

2015-10-21 Thread Wangnan (F)
On 2015/10/22 0:57, Peter Zijlstra wrote: On Wed, Oct 21, 2015 at 11:06:47PM +0800, pi3orama wrote: So explain; how does this eBPF stuff work. I think I get your point this time, and let me explain the eBPF stuff to you. You are aware that BPF programmer can break the system in this way:

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

2015-10-21 Thread Wangnan (F)
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

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

2015-10-21 Thread Wangnan (F)
On 2015/10/21 19:56, Peter Zijlstra wrote: On Wed, Oct 21, 2015 at 07:34:28PM +0800, Wangnan (F) wrote: If you want to actually disable the event: pmu->stop() will make it stop, and you can restart using pmu->start().xiezuo I also prefer totally disabling event because our goal is to

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

2015-10-21 Thread Wangnan (F)
On 2015/10/21 19:33, Peter Zijlstra wrote: On Wed, Oct 21, 2015 at 06:31:04PM +0800, xiakaixu wrote: The RFC patch set contains the necessary commit log [1]. That's of course the wrong place, this should be in the patch's Changelog. It doesn't become less relevant. In some scenarios we

Re: [PATCH net-next 2/3] bpf: introduce bpf_perf_event_output() helper

2015-10-21 Thread Wangnan (F)
On 2015/10/21 18:01, He Kuang wrote: hi, Alexei I've tested the sample in next patch and it works well. I think more work on the perf side needs to be done for parsing PERF_COUNT_SW_BPF_OUTPUT event type, are you working on that? Thank you. We need to add something into parse-event.y/l

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

2015-10-21 Thread Wangnan (F)
On 2015/10/21 17:12, Peter Zijlstra wrote: On Tue, Oct 20, 2015 at 03:53:02PM -0700, Alexei Starovoitov wrote: On 10/20/15 12:22 AM, Kaixu Xia wrote: diff --git a/kernel/events/core.c b/kernel/events/core.c index b11756f..5219635 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c

Re: [RFC PATCH 2/2] bpf: Implement bpf_perf_event_sample_enable/disable() helpers

2015-10-13 Thread Wangnan (F)
On 2015/10/13 13:15, Alexei Starovoitov wrote: On 10/12/15 9:34 PM, Wangnan (F) wrote: On 2015/10/13 12:16, Alexei Starovoitov wrote: On 10/12/15 8:51 PM, Wangnan (F) wrote: why 'set disable' is needed ? the example given in cover letter shows the use case where you want to receive

Re: [RFC PATCH 2/2] bpf: Implement bpf_perf_event_sample_enable/disable() helpers

2015-10-13 Thread Wangnan (F)
On 2015/10/13 18:54, He Kuang wrote: hi, Alexei What about using similar implementation like PERF_EVENT_IOC_SET_OUTPUT, creating a new ioctl like PERF_EVENT_IOC_SET_ENABLER, then let perf to select an event as 'enabler', then BPF can still control one atomic variable to enable/disable a set

Re: [RFC PATCH 1/2] perf: Add the flag sample_disable not to output data on samples

2015-10-12 Thread Wangnan (F)
On 2015/10/12 20:02, Peter Zijlstra wrote: On Mon, Oct 12, 2015 at 09:02:42AM +, Kaixu Xia wrote: --- a/include/linux/perf_event.h +++ b/include/linux/perf_event.h @@ -483,6 +483,8 @@ struct perf_event { perf_overflow_handler_t overflow_handler; void

Re: [RFC PATCH 2/2] bpf: Implement bpf_perf_event_sample_enable/disable() helpers

2015-10-12 Thread Wangnan (F)
On 2015/10/13 3:29, Alexei Starovoitov wrote: On 10/12/15 2:02 AM, Kaixu Xia wrote: +extern const struct bpf_func_proto bpf_perf_event_sample_enable_proto; +extern const struct bpf_func_proto bpf_perf_event_sample_disable_proto; externs are unnecessary. Just make them static. Also I prefer

Re: [RFC PATCH 2/2] bpf: Implement bpf_perf_event_sample_enable/disable() helpers

2015-10-12 Thread Wangnan (F)
On 2015/10/13 12:16, Alexei Starovoitov wrote: On 10/12/15 8:51 PM, Wangnan (F) wrote: why 'set disable' is needed ? the example given in cover letter shows the use case where you want to receive samples only within sys_write() syscall. The example makes sense, but sys_write() is running

Re: [RFC PATCH 2/2] bpf: Implement bpf_perf_event_sample_enable/disable() helpers

2015-10-12 Thread Wangnan (F)
On 2015/10/13 11:39, Alexei Starovoitov wrote: On 10/12/15 8:27 PM, Wangnan (F) wrote: Then how to avoid racing? For example, when one core disabling all events in a map, another core is enabling all of them. This racing may causes sereval perf events in a map dump samples while other events

Re: [PATCH v2] bpf: fix a bug in verification logic when SUB operation taken on FRAME_PTR

2015-06-18 Thread Wangnan (F)
On 2015/6/19 0:00, Alexei Starovoitov wrote: On Thu, Jun 18, 2015 at 08:31:45AM +, Wang Nan wrote: Original code has a problem, cause following code failed to pass verifier: r1 - r10 r1 -= 8 r2 = 8 r3 = unsafe pointer call BPF_FUNC_probe_read -- R1 type=inv expected=fp