Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 5 Jul 2018 09:56:02 -0700
From:   "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To:     Will Deacon <will.deacon@arm.com>
Cc:     Daniel Lustig <dlustig@nvidia.com>,
        Alan Stern <stern@rowland.harvard.edu>,
        Andrea Parri <andrea.parri@amarulasolutions.com>,
        LKMM Maintainers -- Akira Yokosawa <akiyks@gmail.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        David Howells <dhowells@redhat.com>,
        Jade Alglave <j.alglave@ucl.ac.uk>,
        Luc Maranget <luc.maranget@inria.fr>,
        Nicholas Piggin <npiggin@gmail.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] tools/memory-model: Add write ordering by
 release-acquire and by locks
Reply-To: paulmck@linux.vnet.ibm.com
References: <20180704121103.GB26941@arm.com>
 <Pine.LNX.4.44L0.1807051010380.1697-100000@iolanthe.rowland.org>
 <20180705153140.GO3593@linux.vnet.ibm.com>
 <b41849a8-76cd-2375-dd80-c1bdeb9ea7d2@nvidia.com>
 <20180705162225.GH14470@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180705162225.GH14470@arm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Message-Id: <20180705165602.GQ3593@linux.vnet.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Jul 05, 2018 at 05:22:26PM +0100, Will Deacon wrote:
> On Thu, Jul 05, 2018 at 08:44:39AM -0700, Daniel Lustig wrote:
> > On 7/5/2018 8:31 AM, Paul E. McKenney wrote:
> > > On Thu, Jul 05, 2018 at 10:21:36AM -0400, Alan Stern wrote:
> > >> At any rate, it looks like instead of strengthening the relation, I
> > >> should write a patch that removes it entirely.  I also will add new,
> > >> stronger relations for use with locking, essentially making spin_lock
> > >> and spin_unlock be RCsc.
> > > 
> > > Only in the presence of smp_mb__after_unlock_lock() or
> > > smp_mb__after_spinlock(), correct?  Or am I confused about RCsc?
> > > 
> > > 							Thanx, Paul
> > > 
> > 
> > In terms of naming...is what you're asking for really RCsc?  To me,
> > that would imply that even stores in the first critical section would
> > need to be ordered before loads in the second critical section.
> > Meaning that even x86 would need an mfence in either lock() or unlock()?
> 
> I think a LOCK operation always implies an atomic RmW, which will give
> full ordering guarantees on x86. I know there have been interesting issues
> involving I/O accesses in the past, but I think that's still out of scope
> for the memory model.
> 
> Peter will know.

Agreed, x86 locked operations imply full fences, so x86 will order the
accesses in consecutive critical sections with respect to an observer
not holding the lock, even stores in earlier critical sections against
loads in later critical sections.  We have been discussing tightening
LKMM to make an unlock-lock pair order everything except earlier stores
vs. later loads.  (Of course, if everyone holds the lock, they will see
full ordering against both earlier and later critical sections.)

Or are you pushing for something stronger?

							Thanx, Paul