Message-ID: <20190716224606.GD172157@google.com>
Date:   Tue, 16 Jul 2019 18:46:06 -0400
From:   Joel Fernandes <joel@...lfernandes.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        linux-kernel@...r.kernel.org,
        Adrian Ratiu <adrian.ratiu@...labora.com>,
        Alexei Starovoitov <ast@...nel.org>, bpf@...r.kernel.org,
        Brendan Gregg <brendan.d.gregg@...il.com>, connoro@...gle.com,
        Daniel Borkmann <daniel@...earbox.net>,
        duyuchao <yuchao.du@...soc.com>, Ingo Molnar <mingo@...hat.com>,
        jeffv@...gle.com, Karim Yaghmour <karim.yaghmour@...rsys.com>,
        kernel-team@...roid.com, linux-kselftest@...r.kernel.org,
        Manali Shukla <manalishukla14@...il.com>,
        Manjo Raja Rao <linux@...ojrajarao.com>,
        Martin KaFai Lau <kafai@...com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Matt Mullins <mmullins@...com>,
        Michal Gregorczyk <michalgr@...com>,
        Michal Gregorczyk <michalgr@...e.com>,
        Mohammad Husain <russoue@...il.com>, namhyung@...gle.com,
        namhyung@...nel.org, netdev@...r.kernel.org,
        paul.chaignon@...il.com, primiano@...gle.com,
        Qais Yousef <qais.yousef@....com>,
        Shuah Khan <shuah@...nel.org>,
        Song Liu <songliubraving@...com>,
        Srinivas Ramana <sramana@...eaurora.org>,
        Tamir Carmeli <carmeli.tamir@...il.com>,
        Yonghong Song <yhs@...com>
Subject: Re: [PATCH RFC 0/4] Add support to directly attach BPF program to
 ftrace

On Tue, Jul 16, 2019 at 06:31:17PM -0400, Steven Rostedt wrote:
> On Tue, 16 Jul 2019 17:30:50 -0400
> Joel Fernandes <joel@...lfernandes.org> wrote:
> 
> > I don't see why a new bpf node for a trace event is a bad idea, really.
> > tracefs is how we deal with trace events on Android. We do it in production
> > systems. This is a natural extension to that and fits with the security model
> > well.
> 
> What I would like to see is a way to have BPF inject data into the
> ftrace ring buffer directly. There's a bpf_trace_printk() that I find a
> bit of a hack (especially since it hooks into trace_printk() which is
> only for debugging purposes). Have a dedicated bpf ftrace ring
> buffer event that can be triggered is what I am looking for. Then comes
> the issue of what ring buffer to place it in, as ftrace can have
> multiple ring buffer instances. But these instances are defined by the
> tracefs instances directory. Having a way to associate a bpf program to
> a specific event in a specific tracefs directory could allow for ways to
> trigger writing into the correct ftrace buffer.

But his problem is with doing the association of a BPF program with tracefs
itself. How would you attach a BPF program with tracefs without doing a text
based approach? His problem is with the text based approach per his last
email.

> But looking over the patches, I see what Alexei means that there's no
> overlap with ftrace and these patches except for the tracefs directory
> itself (which is part of the ftrace infrastructure). And the trace
> events are technically part of the ftrace infrastructure too. I see the
> tracefs interface being used, but I don't see how the bpf programs
> being added affect the ftrace ring buffer or other parts of ftrace. And
> I'm guessing that's what is confusing Alexei.

In a follow-up patch which I am still writing, I am using the trace ring
buffer as temporary storage since I am formatting the trace event into it.
This patch you are replying to is just for raw tracepoint and yes, I agree
this one does not use the ring buffer, but a future addition to it does. So
I don't think the association of this patch series with ftrace is going to be
an issue IMO.

thanks,

 - Joel

Powered by blists - more mailing lists