On Tue, Feb 26, 2019 at 01:46:01AM -0500, Kris Van Hees wrote: > On Mon, Feb 25, 2019 at 10:18:25PM -0800, Alexei Starovoitov wrote: > > On Mon, Feb 25, 2019 at 07:54:13AM -0800, Kris Van Hees wrote: > > > > > > The goal is to further extend the BPF_PROG_TYPE_GTRACE implementation to > > > support what tracers commonly need, and I am also looking at ways to further > > > extend this model to allow more tracer-specific features as well without the > > > need for adding a BPF program types for every tracer. > > > > It seems by themselves the patches don't provide any new functionality, > > but instead look like plumbing to call external code. > > The patches are definitely not plumbing to call external code, and if I gave > that impression I apologise. I overlooked the information you quote below on > allowing new functionality through modules when I wrote the comment above but > please note that it was a forward-looking comment in terms of what could be > done - not a reason for the patches that I submitted. > > The patches accomplish something that is totally independent from that: they > make it possible for existing events that execute BPF programs when triggered > to transfer control to a BPF program with a more rich context. The first > patch makes such a transfer possible (using tail-call combined with converting > the context to the new program type), and the second patch provides one such > program type (generic trace). The new functionality provided by the program > type is direct access to task information that previously could only be > obtained through helper calls. E.g. the new program type allows programs to > access the task state, prio, ppid, euid, and egid. None of those pieces of > information can currently be obtained unless you start poking around in > memory using bpf_probe_read() helper calls. I don't think I understand the problem you're trying to solve. >From kprobe/tracepoints/etc bpf prog can use bpf_probe_read() to read everything. Are you saying direct access to state, prio, ppid, euid, and egid via context is much superior? Why? Because it's more stable? Why stop at these fields then? task_struct has many others. What we observed that no matter how many fields we add to stable uapi somebody will always request one more. For networking the total number of such fields is contained, but for tracing we're talking about thousands of useful fields. We cannot make them stable. Hence we've been working on alternative approach via BTF to make all of kernel internal fields sort-of stable via 'compile once' technique that we described at the last LPC.
