From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755142AbdKBR0m (ORCPT ); Thu, 2 Nov 2017 13:26:42 -0400 Received: from merlin.infradead.org ([205.233.59.134]:34848 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752408AbdKBR0l (ORCPT ); Thu, 2 Nov 2017 13:26:41 -0400 Date: Thu, 2 Nov 2017 18:26:24 +0100 From: Peter Zijlstra To: Will Deacon Cc: Alan Stern , "Reshetova, Elena" , "linux-kernel@vger.kernel.org" , "gregkh@linuxfoundation.org" , "keescook@chromium.org" , "tglx@linutronix.de" , "mingo@redhat.com" , "ishkamiel@gmail.com" , Paul McKenney , parri.andrea@gmail.com, boqun.feng@gmail.com, dhowells@redhat.com, david@fromorbit.com Subject: Re: [PATCH] refcount: provide same memory ordering guarantees as in atomic_t Message-ID: <20171102172624.qiz2w5szz77sqg7j@hirez.programming.kicks-ass.net> References: <20171102160237.t2xkryg6joskf77y@hirez.programming.kicks-ass.net> <20171102171644.GD595@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171102171644.GD595@arm.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 02, 2017 at 05:16:44PM +0000, Will Deacon wrote: > On Thu, Nov 02, 2017 at 01:08:52PM -0400, Alan Stern wrote: > > Right. To address your point: release + acquire isn't the same as a > > full barrier either. The SB pattern illustrates the difference: > > > > P0 P1 > > Write x=1 Write y=1 > > Release a smp_mb > > Acquire b Read x=0 > > Read y=0 > > > > This would not be allowed if the release + acquire sequence was > > replaced by smp_mb. But as it stands, this is allowed because nothing > > prevents the CPU from interchanging the order of the release and the > > acquire -- and then you're back to the acquire + release case. > > > > However, there is one circumstance where this interchange isn't > > allowed: when the release and acquire access the same memory > > location. Thus: > > > > P0(int *x, int *y, int *a) > > { > > int r0; > > > > WRITE_ONCE(*x, 1); > > smp_store_release(a, 1); > > smp_load_acquire(a); > > r0 = READ_ONCE(*y); > > } > > > > P1(int *x, int *y) > > { > > int r1; > > > > WRITE_ONCE(*y, 1); > > smp_mb(); > > r1 = READ_ONCE(*x); > > } > > > > exists (0:r0=0 /\ 1:r1=0) > > > > This is forbidden. It would remain forbidden even if the smp_mb in P1 > > were replaced by a similar release/acquire pair for the same memory > > location. > > Isn't this allowed on x86 mapping smp_mb() to mfence, store-release to plain > store and load-acquire to plain load? All we're saying is that you can forward > from a release to an acquire, which is fine for RCpc semantics. Yeah, as it happens I talked to Will about that exact case while writing that email :-), this is why he has that thing handy.