Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751902AbbHSDGB (ORCPT ); Tue, 18 Aug 2015 23:06:01 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:13828 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751524AbbHSDGA (ORCPT ); Tue, 18 Aug 2015 23:06:00 -0400 Message-ID: <55D3F261.8030109@huawei.com> Date: Wed, 19 Aug 2015 11:05:05 +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: Alexei Starovoitov , pi3orama , "rostedt@goodmis.org" CC: He Kuang , "masami.hiramatsu.pt@hitachi.com" , "acme@kernel.org" , "a.p.zijlstra@chello.nl" , "mingo@redhat.com" , "namhyung@kernel.org" , "jolsa@kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC PATCH v6 0/2] Make eBPF programs output data to perf References: <1437448130-134621-1-git-send-email-hekuang@huawei.com> <55CD0BCF.2030400@plumgrid.com> <3DE5423D-3E4E-4395-846D-7D5EAD1BB911@163.com> <55CD10EE.7000300@plumgrid.com> In-Reply-To: <55CD10EE.7000300@plumgrid.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 X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.55D3F271.001F,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3c8f0a3beacd8d682195ad4953fa1cac Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1656 Lines: 43 On 2015/8/14 5:49, Alexei Starovoitov wrote: > On 8/13/15 2:35 PM, pi3orama wrote: >> I was thinking about whether to add a "type" field there, so we will >> have an explicit >> mov const instruction before the call instruction, which can act as a >> mark. Also, if >> we generate the type code automatically, a type field in this API can >> make things >> easier since we don't need wrap the user structure in BPF stack. >> However, the >> LLVM side is not ready yet, so we haven't post the new version. > > I think the helper was clean enough. Any type info probably needs to be > done as a side channel and not part of the helper anyway. > But, ok, let's figure out the type stuff first. > Also I don't think you can rely on extra insn in front of a call insn. > Compiler can freely insert other insns there. You don't want to > introduce data flow analysis in elf parser. > I agree with you. I think we can rely on user providing correct type information. Then we should make this two patches go into kernel. Both 1/2 and 2/2 are required. The bug mentioned in patch 1/3 of v5 series (http://lkml.kernel.org/r/1436839171-31527-2-git-send-email-hekuang@huawei.com) has already been fixed by adjusting sample (d6726c8145290bef950ae2538ea6ae1d96a1944b) So we only need these two patches. Currently they can be applied to mainline master clearly since you haven't add new BPF functions. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/