From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752367AbbKKTBN (ORCPT ); Wed, 11 Nov 2015 14:01:13 -0500 Received: from shards.monkeyblade.net ([149.20.54.216]:50099 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751452AbbKKTBM (ORCPT ); Wed, 11 Nov 2015 14:01:12 -0500 Date: Wed, 11 Nov 2015 14:01:06 -0500 (EST) Message-Id: <20151111.140106.1736782849444456527.davem@davemloft.net> To: will.deacon@arm.com Cc: alexei.starovoitov@gmail.com, daniel@iogearbox.net, peterz@infradead.org, arnd@arndb.de, yang.shi@linaro.org, linaro-kernel@lists.linaro.org, eric.dumazet@gmail.com, zlim.lnx@gmail.com, ast@kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, xi.wang@gmail.com, catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, yhs@plumgrid.com, bblanco@plumgrid.com Subject: Re: [PATCH 2/2] arm64: bpf: add BPF XADD instruction From: David Miller In-Reply-To: <20151111174401.GO9562@arm.com> References: <20151111172659.GA86334@ast-mbp.thefacebook.com> <20151111.123548.1039494689070388545.davem@davemloft.net> <20151111174401.GO9562@arm.com> X-Mailer: Mew version 6.6 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Wed, 11 Nov 2015 11:01:11 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Will Deacon Date: Wed, 11 Nov 2015 17:44:01 +0000 > On Wed, Nov 11, 2015 at 12:35:48PM -0500, David Miller wrote: >> From: Alexei Starovoitov >> Date: Wed, 11 Nov 2015 09:27:00 -0800 >> >> > BPF_XADD == atomic_add() in kernel. period. >> > we are not going to deprecate it or introduce something else. >> >> Agreed, it makes no sense to try and tie C99 or whatever atomic >> semantics to something that is already clearly defined to have >> exactly kernel atomic_add() semantics. > > ... and which is emitted by LLVM when asked to compile __sync_fetch_and_add, > which has clearly defined (yet conflicting) semantics. Alexei clearly stated that he knows about this issue and will fully fix this up in LLVM. What more do you need to hear from him once he's stated that he is aware and is working on it? Meanwhile you should make your JIT emit what is expected, rather than arguing to change the semantics. Thanks.