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 S1754007AbbJZM4O (ORCPT <rfc822;w@1wt.eu>);
	Mon, 26 Oct 2015 08:56:14 -0400
Received: from szxga03-in.huawei.com ([119.145.14.66]:46423 "EHLO
	szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753636AbbJZM4K (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 26 Oct 2015 08:56:10 -0400
Message-ID: <562E2293.5090600@huawei.com>
Date: Mon, 26 Oct 2015 20:54:43 +0800
From: "Wangnan (F)" <wangnan0@huawei.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Peter Zijlstra <peterz@infradead.org>,
        Alexei Starovoitov <ast@plumgrid.com>
CC: Ingo Molnar <mingo@kernel.org>, "David S. Miller" <davem@davemloft.net>,
        He Kuang <hekuang@huawei.com>, Kaixu Xia <xiakaixu@huawei.com>,
        "Daniel Borkmann" <daniel@iogearbox.net>, <netdev@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 net-next] bpf: fix bpf_perf_event_read() helper
References: <1445559014-4667-1-git-send-email-ast@kernel.org> <20151023120335.GZ17308@twins.programming.kicks-ass.net> <562A474E.6040401@plumgrid.com> <20151025092142.GB4380@gmail.com> <562D0208.7090608@plumgrid.com> <20151026123200.GT2508@worktop.programming.kicks-ass.net>
In-Reply-To: <20151026123200.GT2508@worktop.programming.kicks-ass.net>
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.0A020204.562E22A6.0017,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: 44465d488c851bb0b8d43a78e6f4ec8d
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org



On 2015/10/26 20:32, Peter Zijlstra wrote:
> On Sun, Oct 25, 2015 at 09:23:36AM -0700, Alexei Starovoitov wrote:
>> bpf_perf_event_read() muxes of -EINVAL into return value, but it's non
>> ambiguous to the program whether it got an error or real counter value.
> How can that be, the (u64)-EINVAL value is a valid counter value..
> unlikely maybe, but still quite possible.
In our real usecase we simply treat return value larger than 
0x7fffffffffffffff
as error result. We can make it even larger, for example, to 
0xffffffffffff0000.
Resuling values can be pre-processed by a script to filter potential 
error result
out so it is not a very big problem for our real usecases.

For a better interface, I suggest

  u64 bpf_perf_event_read(bool *perror);

which still returns counter value through its return value but put error 
code
to stack. Then BPF program can pass NULL to the function if BPF problem
doesn't want to deal with error code.

Thank you.