From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753524AbbKLVZf (ORCPT ); Thu, 12 Nov 2015 16:25:35 -0500 Received: from foss.arm.com ([217.140.101.70]:38311 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751524AbbKLVZd (ORCPT ); Thu, 12 Nov 2015 16:25:33 -0500 Date: Thu, 12 Nov 2015 21:25:35 +0000 From: Will Deacon To: "Paul E. McKenney" Cc: Peter Zijlstra , 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, Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras Subject: Re: [PATCH 4/4] locking: Introduce smp_cond_acquire() Message-ID: <20151112212535.GB23979@arm.com> References: <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> <20151112150822.GD17308@twins.programming.kicks-ass.net> <20151112152042.GC3972@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151112152042.GC3972@linux.vnet.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 [sorry for the late reply, I'm away from my desk until Monday since I'm busy with family issues] On Thu, Nov 12, 2015 at 07:20:42AM -0800, Paul E. McKenney wrote: > On Thu, Nov 12, 2015 at 04:08:22PM +0100, Peter Zijlstra wrote: > > 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. > > So one approach required for one level of hardware and another for the > next level. I can relate to that all too well... :-/ Just to confirm, Peter's correct in that Boqun's litmus test is permitted by the arm64 architecture when the ll/sc spinlock definitions are in use. However, I don't think that strengthening smp_mb__after_unlock_lock is the right way to solve this. I'll reply to the other part of the thread... Will