Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752324AbbKKR5s (ORCPT ); Wed, 11 Nov 2015 12:57:48 -0500 Received: from casper.infradead.org ([85.118.1.10]:50905 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751152AbbKKR5q (ORCPT ); Wed, 11 Nov 2015 12:57:46 -0500 Date: Wed, 11 Nov 2015 18:57:41 +0100 From: Peter Zijlstra To: David Miller Cc: alexei.starovoitov@gmail.com, will.deacon@arm.com, daniel@iogearbox.net, 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 Message-ID: <20151111175741.GR17308@twins.programming.kicks-ass.net> References: <56436420.9090401@iogearbox.net> <20151111162341.GN9562@arm.com> <20151111172659.GA86334@ast-mbp.thefacebook.com> <20151111.123548.1039494689070388545.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151111.123548.1039494689070388545.davem@davemloft.net> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1247 Lines: 30 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. Dave, this really doesn't make any sense to me. __sync primitives have well defined semantics and (e)BPF is violating this. Furthermore, the fetch_and_add (or XADD) name has well defined semantics, which (e)BPF also violates. Atomicy is hard enough as it is, backends giving random interpretations to them isn't helping anybody. It also baffles me that Alexei is seemingly unwilling to change/rev the (e)BPF instructions, which would be invisible to the regular user, he does want to change the language itself, which will impact all 'scripts'. -- 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/