From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932472AbbJOCVj (ORCPT <rfc822;w@1wt.eu>);
	Wed, 14 Oct 2015 22:21:39 -0400
Received: from szxga03-in.huawei.com ([119.145.14.66]:29958 "EHLO
	szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751103AbbJOCVi (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 14 Oct 2015 22:21:38 -0400
Message-ID: <561F0D9D.4000205@huawei.com>
Date: Thu, 15 Oct 2015 10:21:17 +0800
From: xiakaixu <xiakaixu@huawei.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Alexei Starovoitov <ast@plumgrid.com>
CC: <davem@davemloft.net>, <acme@kernel.org>, <mingo@redhat.com>,
        <a.p.zijlstra@chello.nl>, <masami.hiramatsu.pt@hitachi.com>,
        <jolsa@kernel.org>, <daniel@iogearbox.net>, <wangnan0@huawei.com>,
        <linux-kernel@vger.kernel.org>, <pi3orama@163.com>,
        <hekuang@huawei.com>, <netdev@vger.kernel.org>
Subject: Re: [PATCH V2 2/2] bpf: control a set of perf events by creating
 a new ioctl PERF_EVENT_IOC_SET_ENABLER
References: <1444826277-94060-1-git-send-email-xiakaixu@huawei.com> <1444826277-94060-3-git-send-email-xiakaixu@huawei.com> <561EC917.8090001@plumgrid.com>
In-Reply-To: <561EC917.8090001@plumgrid.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.111.101.23]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
	refid=str=0001.0A020202.561F0DAD.0048,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: d38268619bf4a14f0893726dbbd4442a
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

于 2015/10/15 5:28, Alexei Starovoitov 写道:
> On 10/14/15 5:37 AM, Kaixu Xia wrote:
>> +    event->p_sample_disable = &enabler_event->sample_disable;
> 
> I don't like it as a concept and it's buggy implementation.
> What happens here when enabler is alive, but other event is destroyed?
> 
>> --- a/kernel/trace/bpf_trace.c
>> +++ b/kernel/trace/bpf_trace.c
>> @@ -221,9 +221,12 @@ static u64 bpf_perf_event_sample_control(u64 r1, u64 index, u64 flag, u64 r4, u6
>>       struct bpf_array *array = container_of(map, struct bpf_array, map);
>>       struct perf_event *event;
>>
>> -    if (unlikely(index >= array->map.max_entries))
>> +    if (unlikely(index > array->map.max_entries))
>>           return -E2BIG;
>>
>> +    if (index == array->map.max_entries)
>> +        index = 0;
> 
> what is this hack for ?
> 
> Either use notification and user space disable or
> call bpf_perf_event_sample_control() manually for each cpu.

I will discard current implemention that controlling a set of
perf events by the 'enabler' event. Call bpf_perf_event_sample_control()
manually for each cpu is fine. Maybe we can add a loop to control all the
events stored in maps by judging the index, OK?
> 
> 
> 
> .
>