Re: [PATCH 2/5] bpf: Add bpf_perf_event_output_kfunc

From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Network Development <netdev@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>, Andrii Nakryiko <andriin@fb.com>,
	Yonghong Song <yhs@fb.com>, Martin KaFai Lau <kafai@fb.com>,
	Jakub Kicinski <jakub.kicinski@netronome.com>,
	David Miller <davem@redhat.com>
Subject: Re: [PATCH 2/5] bpf: Add bpf_perf_event_output_kfunc
Date: Tue, 7 Jan 2020 14:13:42 -0800	[thread overview]
Message-ID: <CAADnVQKHPk=rcb_aV_SyL5iEyjxHtgv2XnTkDmeKFMHxgF0vbg@mail.gmail.com> (raw)
In-Reply-To: <20200107122513.GH290055@krava>

On Tue, Jan 7, 2020 at 4:25 AM Jiri Olsa <jolsa@redhat.com> wrote:
>
> 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@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.