Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753324AbbKKWV4 (ORCPT ); Wed, 11 Nov 2015 17:21:56 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:32894 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752822AbbKKWVy (ORCPT ); Wed, 11 Nov 2015 17:21:54 -0500 Date: Wed, 11 Nov 2015 23:21:35 +0100 From: Peter Zijlstra To: Alexei Starovoitov Cc: David Miller , 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: <20151111222135.GU17308@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> <20151111175741.GR17308@twins.programming.kicks-ass.net> <20151111181132.GA90947@ast-mbp.thefacebook.com> <20151111183128.GS17308@twins.programming.kicks-ass.net> <20151111184427.GH11639@twins.programming.kicks-ass.net> <20151111185415.GI11639@twins.programming.kicks-ass.net> <20151111195558.GA4173@ast-mbp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151111195558.GA4173@ast-mbp.thefacebook.com> 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: 775 Lines: 20 On Wed, Nov 11, 2015 at 11:55:59AM -0800, Alexei Starovoitov wrote: > Therefore things like memory barriers, full set of atomics are not applicable > in bpf world. There are still plenty of wait-free constructs one can make using them. Say a barrier/rendezvous construct for knowing when an event has happened on all CPUs. But if you really do not want any of that, I suppose that is a valid choice. Is even privileged (e)BPF not allowed things like this? I was thinking the strict no loops stuff was for unpriv (e)BPF only. -- 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/