Having following commands running concurently:

  # perf record -e ftrace:function -a -o krava.data sleep 10
  # perf record -e ftrace:function --filter 'ip == SyS_read' ls

will endup in the latter one failing on the filter
rules and store all functions (in perf.data) as
instructed by the first record instead of just
SyS_read records.

The reason is that we don't check the ftrace_ops that
triggered the event with event's ftrace_ops. Hence
once running together the event from latter perf will
get all the data of the event from the first one.

Fixing this by using ftrace_ops::private value to keep
the perf_event pointer. This way we don't need to search
for triggered event (as tracepoint handler does) and
directly store sample.

Signed-off-by: Jiri Olsa <[email protected]>
---
 include/linux/perf_event.h      |  3 +++
 kernel/events/core.c            | 25 +++++++++++++++++++++++++
 kernel/trace/trace_event_perf.c |  9 ++-------
 3 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index f9828a48f16a..e438f909df31 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1009,6 +1009,9 @@ extern void perf_tp_event(u64 addr, u64 count, void 
*record,
                          int entry_size, struct pt_regs *regs,
                          struct hlist_head *head, int rctx,
                          struct task_struct *task);
+void perf_function_event(struct perf_event *event,
+                        void *record, int entry_size,
+                        struct pt_regs *regs, int rctx);
 extern void perf_bp_event(struct perf_event *event, void *data);
 
 #ifndef perf_misc_flags
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 9fb9d5ef6825..dc98f12c55e2 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7103,6 +7103,31 @@ static void perf_event_free_bpf_prog(struct perf_event 
*event)
        }
 }
 
+#ifdef CONFIG_FUNCTION_TRACER
+void perf_function_event(struct perf_event *event,
+                        void *record, int entry_size,
+                        struct pt_regs *regs, int rctx)
+
+{
+       struct perf_sample_data data;
+       struct perf_raw_record raw = {
+               .size = entry_size,
+               .data = record,
+       };
+
+       if (event->hw.state & PERF_HES_STOPPED)
+               goto out;
+
+       perf_sample_data_init(&data, 0, 0);
+       data.raw = &raw;
+
+       perf_swevent_event(event, 1, &data, regs);
+
+out:
+       perf_swevent_put_recursion_context(rctx);
+}
+#endif /* CONFIG_FUNCTION_TRACER */
+
 #else
 
 static inline void perf_tp_register(void)
diff --git a/kernel/trace/trace_event_perf.c b/kernel/trace/trace_event_perf.c
index 637268855296..396a39988bde 100644
--- a/kernel/trace/trace_event_perf.c
+++ b/kernel/trace/trace_event_perf.c
@@ -318,14 +318,9 @@ perf_ftrace_function_call(unsigned long ip, unsigned long 
parent_ip,
                          struct ftrace_ops *ops, struct pt_regs *pt_regs)
 {
        struct ftrace_entry *entry;
-       struct hlist_head *head;
        struct pt_regs regs;
        int rctx;
 
-       head = this_cpu_ptr(event_function.perf_events);
-       if (hlist_empty(head))
-               return;
-
 #define ENTRY_SIZE (ALIGN(sizeof(struct ftrace_entry) + sizeof(u32), \
                    sizeof(u64)) - sizeof(u32))
 
@@ -339,8 +334,7 @@ perf_ftrace_function_call(unsigned long ip, unsigned long 
parent_ip,
 
        entry->ip = ip;
        entry->parent_ip = parent_ip;
-       perf_trace_buf_submit(entry, ENTRY_SIZE, rctx, 0,
-                             1, &regs, head, NULL);
+       perf_function_event(ops->private, entry, ENTRY_SIZE, &regs, rctx);
 
 #undef ENTRY_SIZE
 }
@@ -349,6 +343,7 @@ static int perf_ftrace_function_register(struct perf_event 
*event)
 {
        struct ftrace_ops *ops = &event->ftrace_ops;
 
+       ops->private = event;
        ops->flags |= FTRACE_OPS_FL_CONTROL;
        ops->func = perf_ftrace_function_call;
        return register_ftrace_function(ops);
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to