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;
Date:   Wed, 4 Jul 2018 16:06:46 +0100
From:   Will Deacon <will.deacon@arm.com>
To:     Mark Rutland <mark.rutland@arm.com>
Cc:     linux-kernel@vger.kernel.org, peterz@infradead.org,
        boqun.feng@gmail.com, Andrea Parri <parri.andrea@gmail.com>
Subject: Re: [PATCHv2 06/11] atomics/treewide: rework ordering barriers
Message-ID: <20180704150645.GJ4828@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: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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 <linux/atomic.h>
> uses to build the wrappers.

Looks like you've renamed these in the patch but not updated the commit
message. Also, to add to the bikeshedding, would it worth adding "rmw" in
there somewhere, e.g. __atomic_post_rmw_fence, since I assume these only
apply to value-returning stuff?

Will