On Tue, Jan 07, 2020 at 02:13:42PM -0800, Alexei Starovoitov wrote:

On Tue, Jan 7, 2020 at 4:25 AM Jiri Olsa [off-list ref] wrote:

quoted

On Mon, Jan 06, 2020 at 03:27:21PM -0800, Alexei Starovoitov wrote:

quoted

On Sun, Dec 29, 2019 at 03:37:37PM +0100, Jiri Olsa wrote:

quoted

Adding support to use perf_event_output in
BPF_TRACE_FENTRY/BPF_TRACE_FEXIT programs.

There are no pt_regs available in the trampoline,
so getting one via bpf_kfunc_regs array.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
 kernel/trace/bpf_trace.c | 67 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 67 insertions(+)

diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index e5ef4ae9edb5..1b270bbd9016 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c

@@ -1151,6 +1151,69 @@ raw_tp_prog_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
    }
 }

+struct bpf_kfunc_regs {
+   struct pt_regs regs[3];
+};
+
+static DEFINE_PER_CPU(struct bpf_kfunc_regs, bpf_kfunc_regs);
+static DEFINE_PER_CPU(int, bpf_kfunc_nest_level);

Thanks a bunch for working on it.

I don't understand why new regs array and nest level is needed.
Can raw_tp_prog_func_proto() be reused as-is?
Instead of patches 2,3,4 ?

I thought that we might want to trace functions within the
raw tracepoint call, which would be prevented if we used
the same nest variable

now I'm not sure if there's not some other issue with nesting
bpf programs like that.. I'll need to check

but nesting is what bpf_raw_tp_nest_level suppose to solve, no?
I just realized that we already have three *_nest_level counters
in that file. Not sure why one is not enough.
There was an issue in the past when tracepoint, kprobe and skb
collided and we had nasty memory corruption, but that was before
_nest_level was introduced. Not sure how we got to three independent
counters.

ok, I'm not sure what was the initial impuls for that now,
I'll make it share the counter with raw tracepoints

jirka