Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753546AbbGNIea (ORCPT ); Tue, 14 Jul 2015 04:34:30 -0400 Received: from casper.infradead.org ([85.118.1.10]:58385 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752611AbbGNIe0 (ORCPT ); Tue, 14 Jul 2015 04:34:26 -0400 Date: Tue, 14 Jul 2015 10:34:15 +0200 From: Peter Zijlstra To: Benjamin Herrenschmidt Cc: "Paul E. McKenney" , Peter Hurley , Will Deacon , "linux-arch@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC PATCH v2] memory-barriers: remove smp_mb__after_unlock_lock() Message-ID: <20150714083415.GH19282@twins.programming.kicks-ass.net> References: <1436789704-10086-1-git-send-email-will.deacon@arm.com> <20150713131143.GY19282@twins.programming.kicks-ass.net> <20150713140915.GD2632@arm.com> <20150713142109.GE2632@arm.com> <20150713155447.GB19282@twins.programming.kicks-ass.net> <20150713182332.GW3717@linux.vnet.ibm.com> <55A41481.7000702@hurleysoftware.com> <20150713201642.GY3717@linux.vnet.ibm.com> <20150713221503.GD19282@twins.programming.kicks-ass.net> <1436827424.3948.239.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1436827424.3948.239.camel@kernel.crashing.org> 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 Content-Length: 1142 Lines: 28 On Tue, Jul 14, 2015 at 08:43:44AM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2015-07-14 at 00:15 +0200, Peter Zijlstra wrote: > > > > This is instead the sequence that is of concern: > > > > > > store a > > > unlock M > > > lock N > > > load b > > > > So its late and that table didn't parse, but that should be ordered too. > > The load of b should not be able to escape the lock N. > > > > If only because LWSYNC is a valid RMB and any LOCK implementation must > > load the lock state to observe it unlocked. > > What happens is that the load passes the store conditional, though it > doesn't pass the load with reserve. However, both store A and unlock M > being just stores with an lwsync, can pass a load, so they can pass the > load with reserve. And thus inside the LL/SC loop, our store A has > passed our load B. Ah cute.. Thanks, clearly I wasn't awake enough anymore :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/