On Thu, Oct 19, 2017 at 11:48:34PM +0100, David Howells wrote:
> Alexei Starovoitov wrote:
>
> > > @@ -65,6 +65,11 @@ BPF_CALL_3(bpf_probe_read, void *, dst, u32, size,
> > > const void *, unsafe_ptr)
> > > {
> > > int ret;
>
On 10/30/17 2:19 PM, Josef Bacik wrote:
From: Josef Bacik
Error injection is sloppy and very ad-hoc. BPF could fill this niche
perfectly with it's kprobe functionality. We could make sure errors are
only triggered in specific call chains that we care about with very
specific situations. Acco
On 10/30/17 2:19 PM, Josef Bacik wrote:
+
+rm -f testfile.img
+dd if=/dev/zero of=testfile.img bs=1M seek=1000 count=1
+DEVICE=$(losetup --show -f testfile.img)
+mkfs.btrfs -f $DEVICE
+mkdir tmpmnt
+./tracex7 $DEVICE
+if [ $? -eq 0 ]
+then
+ echo "SUCCESS!"
+else
+ echo "FAILED!"
+fi
ing and TC classifiers/actions will stay root only.
In parallel the bpf fuzzing effort is ongoing and so far
we've found only one verifier bug and that was already fixed.
The 'constant blinding' pass also being worked on.
It will obfuscate constant-like values that are part of eBPF ISA
p of perf_event.
Signed-off-by: Alexei Starovoitov
---
The charging is agressive and even basic test_maps, test_verifier are
hitting memlock limit, so alternatively we can drop charging
for cap_sys_admin.
---
include/linux/bpf.h |3 +++
include/linux/sched.h |2 +-
kernel/bpf/arraymap.c |
on stack 2 OK
unpriv: read pointer from stack in small chunks OK
unpriv: write pointer into ctx OK
unpriv: write pointer into map elem value OK
unpriv: partial copy of pointer OK
Signed-off-by: Alexei Starovoitov
---
include/linux/bpf.h |3 +
kernel/bpf/syscall.c|
On 10/5/15 2:00 PM, Kees Cook wrote:
On Mon, Oct 5, 2015 at 1:48 PM, Alexei Starovoitov wrote:
>In order to let unprivileged users load and execute eBPF programs
>teach verifier to prevent pointer leaks.
>Verifier will prevent
>- any arithmetic on pointers
> (except R10+Imm w
On 10/5/15 2:16 PM, Andy Lutomirski wrote:
On Mon, Oct 5, 2015 at 2:12 PM, Alexei Starovoitov wrote:
On 10/5/15 2:00 PM, Kees Cook wrote:
On Mon, Oct 5, 2015 at 1:48 PM, Alexei Starovoitov
wrote:
In order to let unprivileged users load and execute eBPF programs
teach verifier to prevent
On 10/5/15 3:02 PM, Kees Cook wrote:
the array maps that hold FDs (BPF_MAP_TYPE_PROG_ARRAY and
>BPF_MAP_TYPE_PERF_EVENT_ARRAY) don't have lookup/update accessors
>from the program side, so programs cannot see or manipulate
>those pointers.
>For the former only bpf_tail_call() is allowed that take
On 10/5/15 3:14 PM, Daniel Borkmann wrote:
One scenario that comes to mind ... what happens when there are kernel
pointers stored in skb->cb[] (either from the current layer or an old
one from a different layer that the skb went through previously, but
which did not get overwritten)?
Socket filt
On 10/6/15 1:39 AM, Daniel Borkmann wrote:
[...] Also classic BPF would then need to test for it, since a socket
filter
doesn't really know whether native eBPF is loaded there or a
classic-to-eBPF
transformed one, and classic never makes use of this. Anyway, it
could be done
by adding a bit flag
On 10/6/15 10:56 AM, Eric Dumazet wrote:
On Tue, 2015-10-06 at 10:50 -0700, Alexei Starovoitov wrote:
was also thinking that we can do it only in paths that actually
have multiple protocol layers, since today bpf is mainly used with
tcpdump(raw_socket) and new af_packet fanout both have cb
On 10/6/15 5:45 AM, Daniel Borkmann wrote:
Should instead something similar be adapted on bpf(2) as well? Or, would
that even be more painful for application developers shipping their stuff
through distros in the end (where they might then decide to just setup
everything BPF-related and then drop
On 10/7/15 3:22 PM, Kees Cook wrote:
Yes, I agree with you that there would be a CVE regardless. I still
>like the option of configurable access, not a big fan of the sysctl
>either. Thinking out loudly, what about a Kconfig option? We started
>out like this on bpf(2) itself (initially under expe
On 10/5/15 1:48 PM, Alexei Starovoitov wrote:
Unprivileged socket filter bpf programs have access to the
following helper functions:
- map lookup/update/delete (but they cannot store kernel pointers into them)
- get_random (it's already exposed to unprivileged user space)
- get_smp_process
nprivileged_bpf_disabled.
This toggle defaults to off (0), but can be set true (1). Once true,
bpf programs and maps cannot be accessed from unprivileged process,
and the toggle cannot be set back to false.
Signed-off-by: Alexei Starovoitov
---
v1->v2:
- sysctl_unprivileged_bpf_disabled
- dr
p of perf_event.
Signed-off-by: Alexei Starovoitov
---
The charging is agressive and even basic test_maps, test_verifier are
hitting memlock limit, so alternatively we can drop charging
for cap_sys_admin.
---
include/linux/bpf.h |3 +++
include/linux/sched.h |2 +-
kernel/bpf/arraymap.c |
fixed.
The 'constant blinding' pass also being worked on.
It will obfuscate constant-like values that are part of eBPF ISA
to make jit spraying attacks even harder.
Alexei Starovoitov (3):
bpf: enable non-root eBPF programs
bpf: charge user for creation of BPF maps and programs
Rx -= imm is not
Signed-off-by: Alexei Starovoitov
---
v1-v2:
- split tests into separate patch
- add tail_call and other tests and explain tests in commit log
---
samples/bpf/libbpf.h|8 +
samples/bpf/test_verifier.c | 357 +--
2 files change
On 10/7/15 11:21 PM, Ingo Molnar wrote:
so I see no reason why unprivileged eBPF couldn't have a sysctl too - with the
default value set to permissive.
agreed. sent out v2 follows 'modules_disabled' style.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On 8/27/15 3:34 PM, David Miller wrote:
From: Alexei Starovoitov
Date: Wed, 26 Aug 2015 23:26:59 -0700
+/* similar to strncpy_from_user() but with extra checks */
+static void probe_read_string(char *buf, int size, long unsafe_ptr)
+{
+ char dst[4];
+ int i = 0;
+
+ size
On 8/27/15 4:43 PM, Steven Rostedt wrote:
On Thu, 27 Aug 2015 16:20:39 -0700 (PDT)
David Miller wrote:
From: Alexei Starovoitov
Date: Thu, 27 Aug 2015 16:06:14 -0700
Fair or you still think it should be per byte copy?
I'm terribly surprised we don't have an equivalent of str
ct2
collect2-13497 [000] d..1 3251.012941: : executed /usr/bin/ld
Suggested-by: Brendan Gregg
Signed-off-by: Alexei Starovoitov
---
v1->v2:
use generalized strncpy_from_unsafe() and
fix the case of multiple '%s' per format string.
kernel/trace/bpf_trace.c | 32 +
v1->v2:
patch 1: generalize FETCH_FUNC_NAME(memory, string) into
strncpy_from_unsafe()
patch 2: use it in bpf_trace_printk
Alexei Starovoitov (2):
lib: introduce strncpy_from_unsafe()
bpf: add support for %s specifier to bpf_trace_printk()
include/linux/uaccess.h |2 ++
kernel/tr
generalize FETCH_FUNC_NAME(memory, string) into
strncpy_from_unsafe() and fix sparse warnings that were
present in original implementation.
Signed-off-by: Alexei Starovoitov
---
include/linux/uaccess.h |2 ++
kernel/trace/trace_kprobe.c | 20
lib
On 8/28/15 2:48 PM, Steven Rostedt wrote:
* On success, returns the length of the string (not including the trailing
>+ * NUL).
I think it includes the NUL.
oops. yes. that was a copy paste from strncpy_from_user comment.
trace_kprobe usage wants NUL to be counted, so I intended to have it
c
On 8/28/15 3:11 PM, Steven Rostedt wrote:
I personally prefer counting the NUL. I've had issues in the past with
the strncpy_from_user() not counting it :-p
agreed. will respin with comment fixed. thank you much for review!
--
To unsubscribe from this list: send the line "unsubscribe linux-ker
ct2
collect2-13497 [000] d..1 3251.012941: : executed /usr/bin/ld
Suggested-by: Brendan Gregg
Signed-off-by: Alexei Starovoitov
---
v1->v2:
use generalized strncpy_from_unsafe() and
fix the case of multiple '%s' per format string.
v2->v3:
no changes
kernel/trace/bpf_trace.c
v2->v3:
fix the comment to mention that strncpy_from_unsafe() returns
the length of the string including the trailing NUL.
v1->v2:
patch 1: generalize FETCH_FUNC_NAME(memory, string) into
strncpy_from_unsafe()
patch 2: use it in bpf_trace_printk
Alexei Starovoitov (2):
lib: int
generalize FETCH_FUNC_NAME(memory, string) into
strncpy_from_unsafe() and fix sparse warnings that were
present in original implementation.
Signed-off-by: Alexei Starovoitov
---
include/linux/uaccess.h |2 ++
kernel/trace/trace_kprobe.c | 20
lib
On 8/28/15 12:05 AM, Wang Nan wrote:
Hi Arnaldo,
This time I adjust all Cc and Link field in each patch.
Four new patches (1,2,3,12/32) is newly introduced for fixing a bug
related to '--filter' option. Patch 06/32 is also modified. Please keep
an eye on it.
Arnaldo, what is the latest news o
allocated length of the dynamic array is embedded in the top
half of __data_loc_##item field. This patch adds new arg type
PRINT_DYNAMIC_ARRAY_LEN to return the length to eval_num_arg(),
Signed-off-by: He Kuang
Acked-by: Namhyung Kim
Tested-by: Alexei Starovoitov
this patch fixes the perf crash
On 8/28/15 12:06 AM, Wang Nan wrote:
his 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/eve
On 8/27/15 3:42 AM, Kaixu Xia wrote:
An example is pasted at the bottom of this cover letter. In that example,
we can get the cpu_cycles and exception taken in sys_write.
$ cat /sys/kernel/debug/tracing/trace_pipe
$ ./perf record --event perf-bpf.o ls
...
cat-1653 [003
On 8/28/15 6:19 PM, Wangnan (F) wrote:
For me, I use bpf_output_trace_data() to output information like PMU count
value. Perf is the only receiver, so global collector is perfect. Could you
please describe your usecase in more detail?
there is a special receiver in user space that only wants th
On 8/28/15 7:15 PM, Wangnan (F) wrote:
I'd like to see whether it is possible to create dynamic tracepoints so
different receivers can listen on different tracepoints.
see my proposal A. I think ftrace instances might work for this.
I'm not sure about 'format' part though. Kernel side shouldn'
On 8/28/15 7:14 PM, xiakaixu wrote:
Right, this is just a little example. Actually, I have tested this
ability on kernel side and user space side, that is kprobe and uprobe.
great to hear.
At this time i wish to get your comment on the current chosen implementation.
Now the struct perf_event_
On 8/28/15 7:36 PM, Wangnan (F) wrote:
For current patch 32/32, I think it is useful enough for some simple cases,
and we have already start using it internally. What about keep it as
what it
is now and create a independent method for your usecase?
well, though the patch is small and contained,
On 8/31/15 7:17 AM, Guenter Roeck wrote:
s390:
kernel/built-in.o: In function `bpf_trace_printk':
bpf_trace.c:(.text+0x116a5c): undefined reference to `strncpy_from_unsafe'
kernel/built-in.o: In function `fetch_memory_string':
trace_kprobe.c:(.text+0x118ee0): undefined reference to `strncpy_from
m_unsafe'
move strncpy_from_unsafe() next to probe_kernel_read/write()
which use the same memory access style.
Reported-by: Fengguang Wu
Reported-by: Guenter Roeck
Fixes: 1a6877b9c0c2 ("lib: introduce strncpy_from_unsafe()")
Signed-off-by: Alexei Starovoitov
---
For configs without kprobes a
On 10/12/15 2:02 AM, Kaixu Xia wrote:
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index f57d7fe..25e073d 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -39,6 +39,7 @@ struct bpf_map {
u32 max_entries;
const struct bpf_map_ops *ops;
struct work_str
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 single helper that takes a flag, so we can extend
On 10/12/15 7:30 PM, xiakaixu wrote:
The proper perf_event_enable/disable are so heavy that another
>mechanism needed? cpu_function_call is probably too much to do
>from bpf program, but that can be simplified?
>Based on the use case from cover letter, sounds like you want
>something like soft_di
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 not. To avoid such
racing
I think some locking must
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 on this cpu, so just
disabling it on the current one is
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 samples only within sys_write() syscall.
T
On 10/13/15 3:54 AM, He Kuang wrote:
If we want perf to reflect as soon as our sample event be generated,
--no-buffering should be used, but this option has a greater
impact on performance.
no_buffering doesn't have to be applied to all events obviously.
--
To unsubscribe from this list: send
On Wed, Sep 09, 2015 at 08:47:24AM -0600, Tycho Andersen wrote:
> On Tue, Sep 08, 2015 at 05:07:03PM -0700, Kees Cook wrote:
> >
> > Yeah, bpf's union looks good. Let's add a "command" flag, though:
> >
> > seccomp(SECCOMP_MODE_FILTER_EBPF, int cmd, union, size);
> >
> > And this cmd could be ADD
On Wed, Sep 09, 2015 at 09:50:35AM -0600, Tycho Andersen wrote:
> > >
> > > That's effectively what this patch does; when the eBPF is loaded via
> > > bpf(), you tell bpf() you want a BPF_PROG_TYPE_SECCOMP, and it invokes
> > > this validation/translation code, i.e. it uses
> > > seccomp_is_valid_a
On Wed, Sep 09, 2015 at 09:37:51AM -0700, Kees Cook wrote:
> On Wed, Sep 9, 2015 at 9:09 AM, Daniel Borkmann wrote:
> > On 09/09/2015 06:07 PM, Alexei Starovoitov wrote:
> >>
> >> On Wed, Sep 09, 2015 at 09:50:35AM -0600, Tycho Andersen wrote:
> &g
On 10/14/15 5:37 AM, Kaixu Xia wrote:
This patch adds the flag sample_disable to control the trace data
output process when perf sampling. By setting this flag and
integrating with ebpf, we can control the data output process and
get the samples we are most interested in.
The bpf helper bpf_perf
On 10/14/15 5:37 AM, Kaixu Xia wrote:
+ event->p_sample_disable = &enabler_event->sample_disable;
I don't like it as a concept and it's buggy implementation.
What happens here when enabler is alive, but other event is destroyed?
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trac
On 10/16/15 3:25 AM, Hannes Frederic Sowa wrote:
Namespaces at some point dealt with the same problem, they nowadays use
bind mounts of/proc/$$/ns/* to some place in the file hierarchy to keep
the namespace alive. This at least allows someone to build up its own
hierarchy with normal unix tools a
On 10/16/15 9:43 AM, Hannes Frederic Sowa wrote:
Hi Alexei,
On Fri, Oct 16, 2015, at 18:18, Alexei Starovoitov wrote:
On 10/16/15 3:25 AM, Hannes Frederic Sowa wrote:
Namespaces at some point dealt with the same problem, they nowadays use
bind mounts of/proc/$$/ns/* to some place in the file
On 10/16/15 10:27 AM, Daniel Borkmann wrote:
but don't know how flexible we are in
terms of adding S_IFBPF to the UAPI.
I don't think it should be a problem. You referred to POSIX Standard in
your other mail but I can't see any reason why not to establish a new
file mode. Anyway, FreeBSD (e.g.
On 10/16/15 10:21 AM, Hannes Frederic Sowa wrote:
Another question:
Should multiple mount of the filesystem result in an empty fs (a new
instance) or in one were one can see other ebpf-fs entities? I think
Daniel wanted to already use the mountpoint as some kind of hierarchy
delimiter. I would ha
On 10/16/15 11:41 AM, Eric W. Biederman wrote:
Daniel Borkmann writes:
On 10/16/2015 07:42 PM, Alexei Starovoitov wrote:
On 10/16/15 10:21 AM, Hannes Frederic Sowa wrote:
Another question:
Should multiple mount of the filesystem result in an empty fs (a new
instance) or in one were one can
On 10/16/15 12:53 PM, Eric W. Biederman wrote:
Alexei Starovoitov writes:
On 10/16/15 11:41 AM, Eric W. Biederman wrote:
[...]
I am missing something.
When I suggested using a filesystem it was my thought there would be
exactly one superblock per map, and the map would be specified at
On 10/16/15 12:42 AM, Kaixu Xia wrote:
This patch adds the flag dump_enable to control the trace data
output process when perf sampling. By setting this flag and
integrating with ebpf, we can control the data output process and
get the samples we are most interested in.
The bpf helper bpf_perf_e
On 10/16/15 12:42 AM, Kaixu Xia wrote:
This patch implements the function that controlling all the perf
events stored in PERF_EVENT_ARRAY maps by setting the parameter
'index' to maps max_entries.
Signed-off-by: Kaixu Xia
---
kernel/trace/bpf_trace.c | 20 ++--
1 file changed
On 10/16/15 4:44 PM, Eric W. Biederman wrote:
Alexei Starovoitov writes:
We can argue about api for 2nd, whether it's mount with fd=1234 string
or else, but for the first mount style doesn't make sense.
Why does mount not make sense? It is exactly what you are looking for
so w
the length of the,
possibly truncated, destination string.
Signed-off-by: Rasmus Villemoes
---
Probably not -stable-worthy. I can only find two callers, one of which
ignores the return value.
good catch.
Acked-by: Alexei Starovoitov
cc-ing original authors where I copy pasted that part from
On 10/17/15 3:48 AM, Wang Nan wrote:
In these 7 patches:
1. perf is able to put values into map:
# perf record -e mybpf.c/maps.values.value=1234/ ...
2. perf is able to control different slots in a map separately:
# perf record -e
mybpf.c/maps.values.value[1,4-6]=1234,maps.values.val
On 10/17/15 4:58 PM, Wangnan (F) wrote:
Can I translate these words into an acked-by?
sorry nope. acks for implementation, but I didn't review it yet.
And what's your PERF_COUNT_SW_BPF_OUTPUT going on? I think based on this
patchset you can test it with perf now.
few more lines would still
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
@@ -6337,6 +6337,9 @@ static int __perf_event_overflow(struct perf_event *event,
irq_work_queue(&even
takes different approach by letting user space
open independent PERF_COUNT_SW_BPF_OUTPUT events, so that program
output won't collide.
Wangnan is working on corresponding perf patches.
Alexei Starovoitov (3):
perf: pad raw data samples automatically
bpf: introduce bpf_perf_event_output() h
dedicated
channel into user space for post-processing of the raw data collected.
Signed-off-by: Alexei Starovoitov
---
include/uapi/linux/bpf.h| 11 ++
include/uapi/linux/perf_event.h |1 +
kernel/bpf/arraymap.c |2 ++
kernel/bpf/verifier.c |3
Performance test and example of bpf_perf_event_output().
kprobe is attached to sys_write() and trivial bpf program streams
pid+cookie into userspace via PERF_COUNT_SW_BPF_OUTPUT event.
Usage:
$ sudo ./bld_x64/samples/bpf/trace_output
recv 2968913 events per sec
Signed-off-by: Alexei Starovoitov
Instead of WARN_ON in perf_event_output() on unpaded raw samples,
pad them automatically.
Signed-off-by: Alexei Starovoitov
---
kernel/events/core.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index
On 10/21/15 5:06 AM, Peter Zijlstra wrote:
PERF_COUNT_SW_DUMMY = 9,
>+ PERF_COUNT_SW_BPF_OUTPUT= 10,
>
>PERF_COUNT_SW_MAX, /* non-ABI */
> };
Do you really need the new type? Can't you use DUMMY for this?
It works fine wit
On 10/21/15 3:02 AM, He Kuang wrote:
Here's a hypothetical scenario to illustrate the use of timer map.
A video frame is updated between frame_refresh_start() and
frame_refresh_end(), in most cases, the interval between these two
functions is less than 40ms, but occasionally over 200ms.
We can
On 10/21/15 4:05 AM, Wangnan (F) wrote:
I think we can
make perf output raw data hexadamically at first.
that would be my suggestion as well.
print it as hex first and when llvm type info is available you can teach
perf to be smarter.
We're working on support for this feature in iovisor/bcc
wit
On 10/21/15 9:57 AM, Peter Zijlstra wrote:
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.
That's actually broken. My fault as well, si
quot;bpf: Implement function bpf_perf_event_read() that get
the selected hardware PMU conuter")
Signed-off-by: Alexei Starovoitov
---
This patch is on top of
http://patchwork.ozlabs.org/patch/533585/
to avoid conflicts.
Even in the worst case the crash is not possible.
Only warn_on_once, so imo n
On 10/21/15 11:34 AM, Thomas Graf wrote:
So far, during this discussion, it was proposed to modify the file system
>to a single-mount one and to stick this under/sys/kernel/bpf/. This
>will not have "real" namespace support either, but it was proposed to
>have a following structure:
>
> /sys/ke
quot;bpf: Implement function bpf_perf_event_read() that get
the selected hardware PMU conuter")
Signed-off-by: Alexei Starovoitov
---
v1->v2: fix compile in case of !CONFIG_PERF_EVENTS
This patch is on top of
http://patchwork.ozlabs.org/patch/533585/
to avoid conflicts.
Even in the worst c
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' c
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
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/maps.pmu_map.event=evt/ --exclude-perf ls
With -v it output:
...
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) &&
+ attr->type != PERF_TYPE_HARDWARE) ||
+attr->inherit) {
This 'if' statement is so complex.
On 10/22/15 6:59 AM, Peter Zijlstra wrote:
+ if (unlikely(event->oncpu != smp_processor_id()))
>+ return -EOPNOTSUPP;
>+
>+ perf_sample_data_init(&sample_data, 0, 0);
>+ sample_data.raw = &raw;
>+ perf_event_output(event, &sample_data, regs);
>+ return 0;
>+}
Note that th
On 10/22/15 12:39 AM, Wangnan (F) wrote:
...
if (!perf_event_can_insert_to_map(attr))
Do you think redability is improved?
yes. makes sense. will respin.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.
On 10/22/15 6:57 AM, Peter Zijlstra wrote:
On Wed, Oct 21, 2015 at 03:58:03PM -0700, Alexei Starovoitov wrote:
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 64754bfecd70..0b6333265872 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3258,7 +3258,7 @@ static
ter perf_event_attrs()
and remove redundant 'extern'.
Fixes: 35578d798400 ("bpf: Implement function bpf_perf_event_read() that get
the selected hardware PMU conuter")
Signed-off-by: Alexei Starovoitov
---
v2->v3:
. refactor checks based on Wangnan's and Peter's feed
On Fri, Sep 04, 2015 at 01:01:20AM +, Michael Tirado wrote:
> Hiyall,
>
> I have created a seccomp white list filter for a program that launches
> other less trustworthy programs. It's working great so far, but I
> have run into a little roadblock. the launcher program needs to call
> execve
On Fri, Sep 04, 2015 at 10:04:19AM -0600, Tycho Andersen wrote:
> seccomp uses eBPF as its underlying storage and execution format, and eBPF
> has features that seccomp would like to make use of in the future. This
> patch adds a formal seccomp type to the eBPF verifier.
>
> The current implementa
;
> Signed-off-by: Tycho Andersen
> CC: Kees Cook
> CC: Will Drewry
> CC: Oleg Nesterov
> CC: Andy Lutomirski
> CC: Pavel Emelyanov
> CC: Serge E. Hallyn
> CC: Alexei Starovoitov
> CC: Daniel Borkmann
> ---
> include/uapi/linux/b
On Fri, Sep 04, 2015 at 01:26:42PM -0700, Kees Cook wrote:
> On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen
> wrote:
> > This patch adds a way for a process that is "real root" to access the
> > seccomp filters of another process. The process first does a
> > PTRACE_SECCOMP_GET_FILTER_FD to get an
On Fri, Sep 04, 2015 at 10:04:23AM -0600, Tycho Andersen wrote:
> This is the final bit needed to support seccomp filters created via the bpf
> syscall.
>
> One concern with this patch is exactly what the interface should look like
> for users, since seccomp()'s second argument is a pointer, we co
On Fri, Sep 04, 2015 at 01:50:55PM -0700, Kees Cook wrote:
> On Fri, Sep 4, 2015 at 1:45 PM, Tycho Andersen
> wrote:
> > On Fri, Sep 04, 2015 at 01:17:30PM -0700, Kees Cook wrote:
> >> On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen
> >> wrote:
> >> > This commit adds a way to dump eBPF programs.
On Fri, Sep 04, 2015 at 10:04:24AM -0600, Tycho Andersen wrote:
> The classic converter generates conditional jumps with:
>
> if (BPF_SRC(fp->code) == BPF_K && (int) fp->k < 0) {
> ...
> } else {
> insn->dst_reg = BPF_REG_A;
> insn->src_reg = BPF_REG_X;
> insn->imm
On Fri, Sep 04, 2015 at 04:43:50PM -0600, Tycho Andersen wrote:
> > The fix should be something like this:
> > diff --git a/net/core/filter.c b/net/core/filter.c
> > index 13079f03902e..05a04ea87172 100644
> > --- a/net/core/filter.c
> > +++ b/net/core/filter.c
> > @@ -478,9 +478,9 @@ do_pass:
> >
On 10/17/15 5:28 AM, Daniel Borkmann wrote:
Anyway, another idea I've been brainstorming with Hannes today a
bit is about the following:
We register two major numbers, one for eBPF maps (X), one for eBPF
progs (Y). A user can either via cmdline call something like ...
mknod /dev/bpf/maps/map_pk
On 10/18/15 9:49 AM, Daniel Borkmann wrote:
Okay, I have pushed some rough working proof of concept here:
https://git.breakpoint.cc/cgit/dborkman/net-next.git/log/?h=ebpf-fds-final5
So the idea eventually had to be slightly modified after giving this
further
thoughts and is the following:
We h
On 10/19/15 7:23 AM, Daniel Borkmann wrote:
The mknod is not the holder but rather the kobject which should be
represented in sysfs will be. So you can still get the map major:minor
by looking up the /dev file in the correspdonding sysfs directory or I
think we should provide a 'unbind' file, whi
On 10/19/15 10:37 AM, Daniel Borkmann wrote:
An eBPF program or map loading/destruction is *not* by any means to be
considered fast-path. We currently hold a global mutex during loading.
So, how can that be considered fast-path? Similarly, socket creation/
destruction is also not fast-path, etc.
On Mon, Oct 19, 2015 at 03:10:46PM +0800, yalin wang wrote:
> This patch change map_lookup_elem() and map_update_elem() function
> to use u64 temp variable if the key_size or value_size is less than
> u64, we don't need use kmalloc() for these small variables.
>
> Signed-off-by: yalin wang
> ---
On 10/19/15 11:46 AM, Hannes Frederic Sowa wrote:
Hi,
On Mon, Oct 19, 2015, at 20:15, Alexei Starovoitov wrote:
On 10/19/15 10:37 AM, Daniel Borkmann wrote:
An eBPF program or map loading/destruction is *not* by any means to be
considered fast-path. We currently hold a global mutex during
On 10/19/15 1:03 PM, Hannes Frederic Sowa wrote:
I doubt it will stay a lightweight feature as it should not be in the
responsibility of user space to provide those debug facilities.
It feels we're talking past each other.
I want to solve 'persistent map' problem.
debugging of maps/progs, hier
On 10/19/15 3:17 PM, Daniel Borkmann wrote:
On 10/19/2015 10:48 PM, Alexei Starovoitov wrote:
On 10/19/15 1:03 PM, Hannes Frederic Sowa wrote:
I doubt it will stay a lightweight feature as it should not be in the
responsibility of user space to provide those debug facilities.
It feels we&#x
101 - 200 of 2341 matches
Mail list logo
