Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp4040539imm; Mon, 25 Jun 2018 08:45:33 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJBD3Ev3GICXPlkbmfPy7I0ihWVN3fSFBwoX/KG5C9RXzsc+VsLTrLvPbXPRfkb5LHh8Iyf X-Received: by 2002:a63:b543:: with SMTP id u3-v6mr11252937pgo.365.1529941533297; Mon, 25 Jun 2018 08:45:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529941533; cv=none; d=google.com; s=arc-20160816; b=BPra1Maezz4z58vfwyu0LHuhpN7Sy1KUZbaPYWpGbBuKYyUXDUj+1h8RvSQySHiua2 FqxRhcqKM6ygAHta2Yf1r50WXBau3Thlgto7KrzxJjCgi0YgbfSC8RTHmloFd/0jzhif n836mOw1ReXUfZfOnAsa5DF+LF2pWSK/a11KSWGZqyAWZ8Fw0Xig0Taz/JDaoZ/gdwYe VlCJ3Qbu9sSZcYRHvGOJi5RANrJzcm1GORlRv5lpiATLQ8TQnwKxB+n1djr22/+AidWd AMeEPCyf22Tmron4aFDelB33UVq/ZUzKEppqhqdc/vdCMVnB2lcBMYDNoFaLJodOcUto EqUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=kdbWBCB3nwcGpobwu4Kooey63r+vTbN2mEZxhqfthHc=; b=yqZZpvbs+33grK5XhMTgvR1JBTEEnWNY9WzTGxma/dpxy/RlVnIbQ5cw8OXMBKiDXn GpGgczGPLlaJG8ZgkNjYM4I25EFoJOtkCI7ihYehJKG1KJQfmLNOaWjxujwXO8l0LyrQ 47OzUF1UANiPdZcadb02hmd+EpgrmFMe2OxD4KVtzUKuV2GOHxlhTAesehleiQWCSx8E mQgDUicKweUOjVL7f67igr2evyTEEqM3XLwGmf7iKACVTQparoWbo0VSEgy/ToZbjgwY f8wPqbGbAMT1tWKUKOUxA9N2zYJyc1SPej9DbNfn6pANWQ+8xbxbZi7BjPB6acY7FEfg zitg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m6-v6si12377509pgm.306.2018.06.25.08.45.18; Mon, 25 Jun 2018 08:45:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752614AbeFYPoH (ORCPT + 99 others); Mon, 25 Jun 2018 11:44:07 -0400 Received: from foss.arm.com ([217.140.101.70]:60366 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751381AbeFYPoE (ORCPT ); Mon, 25 Jun 2018 11:44:04 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1E45A7A9; Mon, 25 Jun 2018 08:44:04 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0AD913F5AF; Mon, 25 Jun 2018 08:44:02 -0700 (PDT) Date: Mon, 25 Jun 2018 16:44:00 +0100 From: Mark Rutland To: linux-kernel@vger.kernel.org, will.deacon@arm.com, peterz@infradead.org, boqun.feng@gmail.com Cc: Andrea Parri Subject: Re: [PATCHv2 06/11] atomics/treewide: rework ordering barriers Message-ID: <20180625154400.3wffxctuzyvlhgd4@lakrids.cambridge.arm.com> References: <20180625105952.3756-1-mark.rutland@arm.com> <20180625105952.3756-7-mark.rutland@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180625105952.3756-7-mark.rutland@arm.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 25, 2018 at 11:59:47AM +0100, Mark Rutland wrote: > Currently architectures can override __atomic_op_*() to define the barriers > used before/after a relaxed atomic when used to build acquire/release/fence > variants. > > This has the unfortunate property of requiring the architecture to define the > full wrapper for the atomics, rather than just the barriers they care about, > and gets in the way of generating atomics which can be easily read. > > Instead, this patch has architectures define an optional set of barriers, > __atomic_mb_{before,after}_{acquire,release,fence}(), which > uses to build the wrappers. > > At the same time, let's avoid any potential reliance on these elsewhere > by ensuring each is undef'd at the end of . > +#undef __atomic_op_acquire > +#undef __atomic_op_release > +#undef __atomic_op_fence > + > +#undef __atomic_acquire_fence > +#undef __atomic_release_fence > +#undef __atomic_pre_fence > +#undef __atomic_post_fence Due to the way preprocessor gets expanded, this happens to break the cmpxchg() wrappers on some architectures. Without re-implementing those with some pretty horrendous static inlines and wrappers to guarantee type invariance, it's not possible to solve that. As agreed over IRC, I've removed the undefs for now. Alas. Mark.