From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753052AbbJNJkc (ORCPT ); Wed, 14 Oct 2015 05:40:32 -0400 Received: from foss.arm.com ([217.140.101.70]:57044 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752130AbbJNJk2 (ORCPT ); Wed, 14 Oct 2015 05:40:28 -0400 Date: Wed, 14 Oct 2015 10:40:27 +0100 From: Will Deacon To: Boqun Feng Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Peter Zijlstra , Ingo Molnar , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Thomas Gleixner , "Paul E. McKenney" , Waiman Long , Davidlohr Bueso Subject: Re: [PATCH v3 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants Message-ID: <20151014094027.GB11874@arm.com> References: <1444659246-24769-1-git-send-email-boqun.feng@gmail.com> <1444659246-24769-7-git-send-email-boqun.feng@gmail.com> <20151013132404.GI21550@arm.com> <20151013143259.GB23991@fixme-laptop.cn.ibm.com> <20151013144333.GN21550@arm.com> <20151013145830.GC23991@fixme-laptop.cn.ibm.com> <20151013150427.GP21550@arm.com> <20151014014735.GF23991@fixme-laptop.cn.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151014014735.GF23991@fixme-laptop.cn.ibm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 14, 2015 at 09:47:35AM +0800, Boqun Feng wrote: > On Tue, Oct 13, 2015 at 04:04:27PM +0100, Will Deacon wrote: > > On Tue, Oct 13, 2015 at 10:58:30PM +0800, Boqun Feng wrote: > > > On Tue, Oct 13, 2015 at 03:43:33PM +0100, Will Deacon wrote: > > > > Putting a barrier in the middle of that critical section is probably a > > > > terrible idea, and that's why I thought you were avoiding it (hence my > > > > > > The fact is that I haven't thought of that way to implement > > > cmpxchg_release before you ask that question ;-) And I'm not going to do > > > that for now and probably not in the future. > > > > > > > original question). Perhaps just add a comment to that effect, since I > > > > > > Are you suggesting if I put a barrier in the middle I'd better to add a > > > comment, right? So if I don't do that, it's OK to let this patch as it. > > > > No, I mean put a comment in your file to explain the reason why you > > override _relaxed and _acquire, but not _release (because overriding > > You mean overriding _acquire and fully order version, right? Yes, my mistake. Sounds like you get my drift, though. Will