From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754794AbbKLPIf (ORCPT ); Thu, 12 Nov 2015 10:08:35 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:46006 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754462AbbKLPIe (ORCPT ); Thu, 12 Nov 2015 10:08:34 -0500 Date: Thu, 12 Nov 2015 16:08:22 +0100 From: Peter Zijlstra To: "Paul E. McKenney" Cc: Oleg Nesterov , Boqun Feng , mingo@kernel.org, linux-kernel@vger.kernel.org, corbet@lwn.net, mhocko@kernel.org, dhowells@redhat.com, torvalds@linux-foundation.org, will.deacon@arm.com, Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras Subject: Re: [PATCH 4/4] locking: Introduce smp_cond_acquire() Message-ID: <20151112150822.GD17308@twins.programming.kicks-ass.net> References: <20151102134941.005198372@infradead.org> <20151103175958.GA4800@redhat.com> <20151111093939.GA6314@fixme-laptop.cn.ibm.com> <20151111121232.GN17308@twins.programming.kicks-ass.net> <20151111193953.GA23515@redhat.com> <20151112070915.GC6314@fixme-laptop.cn.ibm.com> <20151112150058.GA30321@redhat.com> <20151112144004.GU3972@linux.vnet.ibm.com> <20151112145013.GB17308@twins.programming.kicks-ass.net> <20151112150149.GY3972@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151112150149.GY3972@linux.vnet.ibm.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 On Thu, Nov 12, 2015 at 07:01:49AM -0800, Paul E. McKenney wrote: > On Thu, Nov 12, 2015 at 03:50:13PM +0100, Peter Zijlstra wrote: > > On Thu, Nov 12, 2015 at 06:40:04AM -0800, Paul E. McKenney wrote: > > > I cannot resist suggesting that any lock that interacts with > > > spin_unlock_wait() must have all relevant acquisitions followed by > > > smp_mb__after_unlock_lock(). > > > > Ha! that would certainly help here. But it would mean that argh64v8 also > > needs to define that, even though that is already RCsc. > > Maybe. It could also be that arm64 avoids the need somehow, for example > via their RCsc behavior. Their memory model is similar to PPC, but not > exactly the same. > > Will? So when I spoke to Will earlier today, we agreed that LDAXR+STXR is susceptible to the same problem. The STXR will allow loads to pass up over that store. On v8.1, which is using LDADDA, this is not an issue, for as the ACQUIRE is part of the LOAD, the Read-Modify-Write is indivisible as a whole, and therefore a subsequent load has nothing to pass over.