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, 25 Apr 2019 09:34:42 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Paul Burton <paul.burton@mips.com>
Cc:     "stern@rowland.harvard.edu" <stern@rowland.harvard.edu>,
        "akiyks@gmail.com" <akiyks@gmail.com>,
        "andrea.parri@amarulasolutions.com" 
        <andrea.parri@amarulasolutions.com>,
        "boqun.feng@gmail.com" <boqun.feng@gmail.com>,
        "dlustig@nvidia.com" <dlustig@nvidia.com>,
        "dhowells@redhat.com" <dhowells@redhat.com>,
        "j.alglave@ucl.ac.uk" <j.alglave@ucl.ac.uk>,
        "luc.maranget@inria.fr" <luc.maranget@inria.fr>,
        "npiggin@gmail.com" <npiggin@gmail.com>,
        "paulmck@linux.ibm.com" <paulmck@linux.ibm.com>,
        "will.deacon@arm.com" <will.deacon@arm.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "torvalds@linux-foundation.org" <torvalds@linux-foundation.org>
Subject: Re: [RFC][PATCH 4/5] mips/atomic: Fix smp_mb__{before,after}_atomic()
Message-ID: <20190425073442.GW11158@hirez.programming.kicks-ass.net>
References: <20190424123656.484227701@infradead.org>
 <20190424124421.751367532@infradead.org>
 <20190424212422.bykvyho3jqw6jz6w@pburton-laptop>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190424212422.bykvyho3jqw6jz6w@pburton-laptop>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Apr 24, 2019 at 09:24:31PM +0000, Paul Burton wrote:
> Hi Peter,
> 
> On Wed, Apr 24, 2019 at 02:37:00PM +0200, Peter Zijlstra wrote:
> > --- a/arch/mips/include/asm/barrier.h
> > +++ b/arch/mips/include/asm/barrier.h
> > @@ -230,9 +238,6 @@
> >  #define nudge_writes() mb()
> >  #endif
> >  
> > -#define __smp_mb__before_atomic()	__smp_mb__before_llsc()
> > -#define __smp_mb__after_atomic()	smp_llsc_mb()
> > -
> >  /*
> >   * Some Loongson 3 CPUs have a bug wherein execution of a memory access (load,
> >   * store or pref) in between an ll & sc can cause the sc instruction to
> 
> I think this bit should be part of patch 3, where you currently add a
> second definition of these 2 macros.

Whoops, indeed.

> Otherwise this one looks reasonable to me.

Great, thanks!