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 S1753242AbbGaIvx (ORCPT <rfc822;w@1wt.eu>);
	Fri, 31 Jul 2015 04:51:53 -0400
Received: from szxga03-in.huawei.com ([119.145.14.66]:52087 "EHLO
	szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753085AbbGaIvs (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 31 Jul 2015 04:51:48 -0400
Message-ID: <55BB36C9.4050007@huawei.com>
Date: Fri, 31 Jul 2015 16:50: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: Daniel Borkmann <daniel@iogearbox.net>, <davem@davemloft.net>,
        <acme@kernel.org>, <mingo@redhat.com>, <a.p.zijlstra@chello.nl>,
        <masami.hiramatsu.pt@hitachi.com>, <jolsa@kernel.org>,
        <wangnan0@huawei.com>, <linux-kernel@vger.kernel.org>,
        <pi3orama@163.com>, <hekuang@huawei.com>
Subject: Re: [PATCH v4 1/4] bpf: Make the bpf_prog_array_map more generic
References: <1438082255-60683-1-git-send-email-xiakaixu@huawei.com> <1438082255-60683-2-git-send-email-xiakaixu@huawei.com> <55B95F06.4040800@iogearbox.net> <55B9816B.5020801@plumgrid.com>
In-Reply-To: <55B9816B.5020801@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.0A020204.55BB3715.009C,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: de70d0dff08291a065101cca8f3b7bb9
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

于 2015/7/30 9:44, Alexei Starovoitov 写道:
> On 7/29/15 4:17 PM, Daniel Borkmann wrote:
>>> -    if (map->map_type == BPF_MAP_TYPE_PROG_ARRAY)
>>> +    if (map->map_type >= BPF_MAP_TYPE_PROG_ARRAY)
>>>           /* prog_array stores refcnt-ed bpf_prog pointers
>>>            * release them all when user space closes prog_array_fd
>>>            */
>>> -        bpf_prog_array_map_clear(map);
>>> +        bpf_fd_array_map_clear(map);
>>
>> When we are going to add a new map type to the eBPF framework that is not
>> an fd_array_map thing, this assumption of map->map_type >=
>> BPF_MAP_TYPE_PROG_ARRAY
>> might not hold then ...
> 
> Also I think here changing == to >= is probably unnecessary.
> prog_array needs to do it because of circular dependency
> whereas perf_event_array cannot have it.
> Even when we attach bpf prog to perf_event and then add it to
> perf_event_array used by the same prog, right?
> Please test such scenario just in case.

Not sure completely understand what you mean. You know, we can
attach bpf_prog to kprobe events. For now, we limit few event
types, only PERF_EVENT_RAW & PERF_EVENT_HARDWARE event can
be accessed in bpf_perf_event_read(). Seems like the dependency
scenario won't happen.
I will add the event decrement refcnt function to map_free in V5.
right?
> 
> 
> .
>