From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932687AbbJPTGy (ORCPT ); Fri, 16 Oct 2015 15:06:54 -0400 Received: from casper.infradead.org ([85.118.1.10]:40542 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752345AbbJPTGw (ORCPT ); Fri, 16 Oct 2015 15:06:52 -0400 Date: Fri, 16 Oct 2015 21:06:48 +0200 From: Peter Zijlstra To: Catalin Marinas Cc: "Paul E. McKenney" , Will Deacon , Linux Kernel Mailing List , Oleg Nesterov , Ingo Molnar Subject: Re: Q: schedule() and implied barriers on arm64 Message-ID: <20151016190648.GC3816@twins.programming.kicks-ass.net> References: <20151016151830.GZ3816@twins.programming.kicks-ass.net> <20151016160422.GQ3910@linux.vnet.ibm.com> <20151016161608.GA3816@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Fri, Oct 16, 2015 at 05:55:35PM +0100, Catalin Marinas wrote: > arm64 indeed does not have a dmb after spin_lock, it only has a > load-acquire. So with the default smp_mb__before_spinlock() + > spin_lock we have: > > smp_wmb() > loop > load-acquire > store > > So (I think) this guarantees that any writes before wmb+lock would be > visible before any reads _and_ writes after wmb+lock. However, the > ordering with reads before wmb+lock is not guaranteed. That is my understanding as well, and stores could creep up from below the unlock and then the reads and those stores can cross and you've lost. In any case, its all moot now, since Paul no longer requires schedule() to imply a full barrier.