Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752680AbdHBIq4 (ORCPT <rfc822;w@1wt.eu>);
        Wed, 2 Aug 2017 04:46:56 -0400
Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:50024 "EHLO
        foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752493AbdHBIqy (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 2 Aug 2017 04:46:54 -0400
Date: Wed, 2 Aug 2017 09:46:54 +0100
From: Will Deacon <will.deacon@arm.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
        Boqun Feng <boqun.feng@gmail.com>, linux-kernel@vger.kernel.org,
        Ingo Molnar <mingo@kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
        Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [RFC][PATCH v3]: documentation,atomic: Add new documents
Message-ID: <20170802084653.GD15219@arm.com>
References: <20170731090535.rjgnoewqg7mhzr55@hirez.programming.kicks-ass.net>
 <20170731110403.ou3zqsp3uviqorkz@tardis>
 <20170731174345.GL3730@linux.vnet.ibm.com>
 <20170801090121.edo7mekhw3sann4h@hirez.programming.kicks-ass.net>
 <20170801101900.GB8702@arm.com>
 <20170801114744.evjjfviqhu5kgu7v@hirez.programming.kicks-ass.net>
 <20170801121713.GH8702@arm.com>
 <20170801161412.GW3730@linux.vnet.ibm.com>
 <20170801164200.oczql3m4f3zn6rin@hirez.programming.kicks-ass.net>
 <20170801221818.GN3730@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170801221818.GN3730@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1238
Lines: 32

On Tue, Aug 01, 2017 at 03:18:18PM -0700, Paul E. McKenney wrote:
> On Tue, Aug 01, 2017 at 06:42:00PM +0200, Peter Zijlstra wrote:
> > On Tue, Aug 01, 2017 at 09:14:12AM -0700, Paul E. McKenney wrote:
> > > So if ARM really needs the litmus test with smp_rmb() to be allowed,
> > > we need to adjust the Linux-kernel memory model appropriately.  Which
> > > means that one of us needs to reach out to the usual suspects.  Would
> > > you like to do that, or would you like me to?
> > 
> > I'm really sad ARM8.1 LSE breaks this stuff.. It is rather counter
> > intuitive (then again, we _are_ talking barriers).
> 
> No argument.
> 
> Then again, when we said that the Linux kernel memory model would
> have a non-trivial rate of change, we weren't joking.
> 
> Will, is this the official description?
> 
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0557a.b/index.html
> 
> If so, is B6.1 what we should be looking at?

Sorry it's so tricky to find. The architecture document is here:

https://static.docs.arm.com/ddi0487/b/DDI0487B_a_armv8_arm.pdf

and in section C3.2.13 ("Atomic memory operations") it states:

| The ST<OP> instructions are not regarded as doing a read for the purpose
| of a DMB LD barrier.

Will