From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sat, 28 Feb 2015 15:34:02 -0800 From: "Paul E. McKenney" To: Peter Zijlstra Cc: Manfred Spraul , Oleg Nesterov , LKML , 1vier1@web.de, Kirill Tkhai , Ingo Molnar , Josh Poimboeuf , stable@vger.kernel.org Subject: Re: [PATCH] ipc/sem.c: Update/correct memory barriers. Message-ID: <20150228233401.GM15405@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <1425155775-23909-1-git-send-email-manfred@colorfullife.com> <20150228214533.GY5029@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150228214533.GY5029@twins.programming.kicks-ass.net> Sender: linux-kernel-owner@vger.kernel.org List-ID: On Sat, Feb 28, 2015 at 10:45:33PM +0100, Peter Zijlstra wrote: > On Sat, Feb 28, 2015 at 09:36:15PM +0100, Manfred Spraul wrote: > > +/* > > + * Place this after a control barrier (such as e.g. a spin_unlock_wait()) > > + * to ensure that reads cannot be moved ahead of the control_barrier. > > + * Writes do not need a barrier, they are not speculated and thus cannot > > + * pass the control barrier. > > + */ > > +#ifndef smp_mb__after_control_barrier > > +#define smp_mb__after_control_barrier() smp_rmb() > > +#endif > > Sorry to go bike shedding again; but should we call this: > > smp_acquire__after_control_barrier() ? > > The thing is; its not a full MB because: > > - stores might actually creep into it; while the control dependency > guarantees stores will not creep out, nothing is stopping them from > getting in; > > - its not transitive, and our MB is defined to be so. > > Oleg, Paul? The idea is that this would become a no-op on x86, s390, sparc &c, an isb instruction on ARM, an isync instruction on Power, and I cannot remember what on Itanium? The other idea being to provide read-to-read control ordering in addition to the current read-to-write control ordering? Thanx, Paul