On Mon, Jan 06, 2020 at 03:27:21PM -0800, Alexei Starovoitov wrote:
> On Sun, Dec 29, 2019 at 03:37:37PM +0100, Jiri Olsa wrote:
> > 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@xxxxxxxxxx>
> > ---
> > 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
jirka
