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 req
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
Acked-by: Daniel Borkmann
Acked-by: Martin KaFai Lau
---
tools/lib
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 +--
tools/lib/bpf/libbpf.h | 2 ++
2 files changed, 3 insertions(+), 2
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
Acked-by: Daniel
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
---
tools/include/uapi/linux/bpf.h | 24
tools/lib/b
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
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
tools/lib/bpf/bpf.c| 24
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 to be
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, veth
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
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 +--
tools/lib/bpf/libbpf.h | 1 +
2 files changed, 2 insertions(+), 2 de
On 2017/2/15 1:07, David Miller wrote:
From: "Wangnan (F)"
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 the bpf_sys.h file.
Signed-off-b
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
Cc: David S. Miller
Cc: Wang Nan
Link: https://lkm
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 o
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
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Shuah Khan
---
tools/lib/bpf/bpf.c | 6
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 ++
tools/testing/selftests/bpf/bpf_sys.h | 27
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 | 6 +++---
tools/lib/bpf/bpf.h
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 Borkmann
Cc: Wang Nan
---
tools/lib/bpf/bpf.h | 1 +
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
---
tools/lib/bpf/bpf.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/lib/bpf/bpf.h
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 Sal
On 2017/1/25 9:16, Joe Stringer wrote:
On 24 January 2017 at 17:06, Wangnan (F) 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 within a BPF filesystem to
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
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
---
v
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
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 +-
samples/bp
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 6c90598174322b029e40dd84a4eb01f56afe in
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"
---
tools/lib/bpf/bpf.c | 4
On 2016/11/17 10:46, Joe Stringer wrote:
On 16 November 2016 at 18:10, Wangnan (F) 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
gradually, instead of a full
On 2016/11/17 10:46, Joe Stringer wrote:
On 16 November 2016 at 18:10, Wangnan (F) 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
gradually, instead of a full
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/ versio
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 ++
1 file change
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.
So
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 no
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 error handling func
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
cor
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
---
tools/lib/bpf/bp
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 7cd341e..1fe4532 100644
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
---
tools/lib/bpf/libbpf.c | 19 +++
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 b/tools/include/u
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 wil
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
---
tools/lib/bpf/libbpf.c | 15 +++
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 +
tools/lib/bpf/libbpf.h | 1 -
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:
tools/lib/bpf/libbp
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).
Thi
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 value
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 bp
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 can
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 can
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, i
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 rec
On 2015/10/22 15:39, Ingo Molnar wrote:
* Wangnan (F) 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 core, so it
can't
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) &&
+
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 can
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_
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
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
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:
A=
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?
Than
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
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
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 don
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
@@
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 t
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 o
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
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
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
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 s
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
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
Howev
70 matches
Mail list logo
