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 inlin
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 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 inline u64 perf_event_count(struct perf_e
On Thu, Oct 22, 2015 at 08:30:36PM +0800, Wangnan (F) wrote:
> I have a question on inherit, not related to this patch:
> Is it safe for perf to disable attr->inherit if the event is system wide?
> I haven't read relate code completely. In my current knowledge the behavior
> of a system wide perf e
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 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) &&
+ attr->type != PERF_TYPE_HARDWARE) ||
+attr
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 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_map.c/maps.pmu_map.eve
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:
...
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
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 cause kernel splat.
Fixes: 35578d798400 ("bpf: Im
12 matches
Mail list logo
