From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753782AbbJUOJc (ORCPT ); Wed, 21 Oct 2015 10:09:32 -0400 Received: from casper.infradead.org ([85.118.1.10]:57293 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752389AbbJUOJa (ORCPT ); Wed, 21 Oct 2015 10:09:30 -0400 Date: Wed, 21 Oct 2015 16:09:21 +0200 From: Peter Zijlstra To: pi3orama Cc: "Wangnan (F)" , Alexei Starovoitov , xiakaixu , davem@davemloft.net, acme@kernel.org, mingo@redhat.com, masami.hiramatsu.pt@hitachi.com, jolsa@kernel.org, daniel@iogearbox.net, linux-kernel@vger.kernel.org, hekuang@huawei.com, netdev@vger.kernel.org Subject: Re: [PATCH V5 1/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling Message-ID: <20151021140921.GI3604@twins.programming.kicks-ass.net> References: <1445325735-121694-2-git-send-email-xiakaixu@huawei.com> <5626C5CE.8080809@plumgrid.com> <20151021091254.GF2881@worktop.programming.kicks-ass.net> <56276968.6070604@huawei.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1D2C9396-01CB-4981-B493-EA311F0457E7@163.com> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 21, 2015 at 10:01:46PM +0800, pi3orama wrote: > > 在 2015年10月21日,下午9:49,Peter Zijlstra 写道: > > > >> On Wed, Oct 21, 2015 at 09:42:12PM +0800, Wangnan (F) wrote: > >> How can an eBPF program access a !local event: > >> > >> when creating perf event array we don't care which perf event > >> is for which CPU, so perf program can access any perf event in > >> that array. > > > > So what is stopping the eBPF thing from calling perf_event_read_local() > > on a !local event and triggering a kernel splat? > > I can understand the perf_event_read_local() case, but I really can't understand > what is stopping us to write to an atomic field belong to a !local perf event. > Could you please give a further explanation? I simply do not get how this eBPF stuff works. Either I have access to !local events and I can hand one to perf_event_read_local() and cause badness, or I do not have access to !local events and the whole 'soft enable/disable' thing is simple. They cannot be both true. So explain; how does this eBPF stuff work.