On Wed, Oct 21, 2015 at 11:06:47PM +0800, pi3orama wrote: > > So explain; how does this eBPF stuff work. > > I think I get your point this time, and let me explain the eBPF stuff to you. > > You are aware that BPF programmer can break the system in this way: > > A=get_non_local_perf_event() > perf_event_read_local(A) > BOOM! > > However the above logic is impossible because BPF program can't work this > way. > > First of all, it is impossible for a BPF program directly invoke a > kernel function. Doesn't like kernel module, BPF program can only > invoke functions designed for them, like what this patch does. So the > ability of BPF programs is strictly restricted by kernel. If we don't > allow BPF program call perf_event_read_local() across core, we can > check this and return error in function we provide for them. > > Second: there's no way for a BPF program directly access a perf event. > All perf events have to be wrapped by a map and be accessed by BPF > functions described above. We don't allow BPF program fetch array > element from that map. So pointers of perf event is safely protected > from BPF program. > > In summary, your either-or logic doesn't hold in BPF world. A BPF > program can only access perf event in a highly restricted way. We > don't allow it calling perf_event_read_local() across core, so it > can't.
Urgh, that's still horridly inconsistent. Can we please come up with a consistent interface to perf? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
