From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753931AbbJVH5F (ORCPT ); Thu, 22 Oct 2015 03:57:05 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:2217 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750961AbbJVH5D (ORCPT ); Thu, 22 Oct 2015 03:57:03 -0400 Message-ID: <56289589.1030008@huawei.com> Date: Thu, 22 Oct 2015 15:51:37 +0800 From: "Wangnan (F)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ingo Molnar CC: Peter Zijlstra , pi3orama , Alexei Starovoitov , xiakaixu , , , , , , , , , Subject: Re: [PATCH V5 1/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling References: <20151021113316.GM17308@twins.programming.kicks-ass.net> <56277BCE.6030400@huawei.com> <20151021121713.GC3604@twins.programming.kicks-ass.net> <56279634.5000606@huawei.com> <20151021134951.GH3604@twins.programming.kicks-ass.net> <1D2C9396-01CB-4981-B493-EA311F0457E7@163.com> <20151021140921.GI3604@twins.programming.kicks-ass.net> <586A5B33-C9C9-433D-B6E9-019264BF7DDB@163.com> <20151021165758.GK3604@twins.programming.kicks-ass.net> <56284E03.1020008@huawei.com> <20151022073959.GA18791@gmail.com> In-Reply-To: <20151022073959.GA18791@gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.111.66.109] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2015/10/22 15:39, Ingo Molnar wrote: > * Wangnan (F) wrote: > [SNIP] >> >> 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? >> BPF program and kernel module are two different worlds as I said before. >> >> I don't think making them to share a common interface is a good idea because >> such sharing will give BPF programs too much freedom than it really need, then >> it will be hard prevent them to do something bad. If we really need kernel >> interface, I think what we need is kernel module, not BPF program. > What do you mean, as this does not parse for me. Because I'm not very sure what the meaning of "inconsistent" in Peter's words... I think what Peter want us to do is to provide similar (consistent) interface between kernel and eBPF that, if kernel reads from a perf_event through perf_event_read_local(struct perf_event *), BPF program should do this work with similar code, or at least similar logic, so we need to create handler for a perf event, and provide a BPF function called BPF_FUNC_perf_event_read_local then pass such handler to it. I don't think like this because if we want kernel interface we'd better use kernel module, not eBPF so I mentioned kernel module here. Ingo, do you think BPF inerface should be *consistent* with anything? Thank you. > We obviously can (and very likely should) make certain perf functionality > available to BPF programs. > > It should still be a well defined yet flexible iterface, with safe behavior, > obviously - all in line with existing BPF sandboxing principles. > > 'Kernel modules' don't enter this consideration at all, not sure why you mention > them - all this functionality is also available if CONFIG_MODULES is turned off > completely. > > Thanks, > > Ingo >