Re: [PATCH 0/2] bpf: context casting for tail call and gtrace prog type

On Mon, Mar 11, 2019 at 8:24 PM Kris Van Hees [off-list ref] wrote:

On Mon, Mar 11, 2019 at 06:29:55PM -0700, Brendan Gregg wrote:

quoted

On Mon, Mar 11, 2019 at 7:21 AM Kris Van Hees [off-list ref] wrote:

quoted

On Thu, Mar 07, 2019 at 01:30:37PM -0800, Alexei Starovoitov wrote:

quoted

On Tue, Mar 05, 2019 at 09:03:57PM -0500, Kris Van Hees wrote:

[...]

quoted

quoted

quoted

But being able to do things like this without
needing to touch the context of any other BPF program type is a great benefit
to offer tracing tools, as far as I see it.

I still don't understand what you're referring to by 'things like this'
that somehow will be possible in the future, but not possible today.
Could you please give concrete example?

My apologies for not being clear.  I am referring to the features of the
gtrace context in terms of containing task information, and output buffers
to be used in BPF programs triggered from various probe sources (kprobe,
tracepoints, ...)  I would not want to suggest making changes to all the
different program contexts in order to support tracing needs because that
would be wrong.  Doing it in a central place makes it a lot easier to maintain
without impacting other program types, etc.

Of course, yes, bpf_probe_read() and bpf_perf_event_output() can be used
to implement a lot of what existing tracing tools like DTrace can do, if you
write them based on that.  One limitations I am obviously working with is
that DTrace already exists and has existed for a long time.  And while it is
100% available as open source, it involves a pretty involved set of patches to
be applied to the kernel to be able to use it which is just not ideal.  Hence
the goal to make it available by re-using as much of the existing features in
Linux as possible, while still maintaining the same level of functionality in
DTrace.  That means we need to fill the gaps - and from where I am sitting,
the ways to do that might as well be of use to others (if they want to).

If phrasing things in the context of DTrace would make the conversation easier
I certainly don;t mind doing that, but I really don't want to limit my patches
to supporting just DTrace (even if right now it might be the only tracer using
it).

As a concrete example, can you point to one of my own published DTrace
tools that BPF can't do? These were created to solve many real
production issues, and make good use cases. I've been porting them
over to BPF (bcc and bpftrace) without too much problem, and I can't
think of a single one that I couldn't port over today.

I am unclear how pointing at one of your published DTrace tools would
contribute to this discussion.  Surely the scope of use cases is not limited
to the DTrace scripts you published?

Either way, one of the features that I make use of is speculative tracing.

The subject was a concrete example. I don't think I used speculative
tracing in any of my scripts. Can you pick a better example of
something BPF can't do?

And yes, even that could be handled with some ugly workarounds but my intent
is to implement things in a more clean way rather than depending on a bunch
of workarounds to make it somewhat work.

quoted

There's a few minor things that I'm currently doing workarounds for,
like ppid, but that should be satisfied with a few more helpers. And
if it's really niche, then BTF sounds like a good solution.

Of course, we can always add more helpers to get to information that is
needed, but that is hardly a practical solution in the long run, and at
Plumbers 2019 it was already indicated that just adding helpers to get to
more information about tasks is not the route people want to take.

quoted

If your ultimate goal is to have a command called "dtrace" that runs D
programs, to support your existing users, then I'd add a lex/yacc pair
to bpftrace and have it emit a dtrace binary.

My goal is not to have a command called dtarce that somehow simply provides
some form of support for dtrace scripts in some legacy support model.  My
goal is to make DTrace available on Linux based on existing kernel features
(and contirbuting extra features where needed, in a collaborative manner).

If bpftrace builds a dtrace binary that runs D code, then you just did
make DTrace available on Linux.

And without changing the kernel.

Brendan

-- 
Brendan Gregg, Senior Performance Architect, Netflix