On Wed, Jan 27, 2016 at 03:00:11PM -0800, Paul E. McKenney wrote:

On Wed, Jan 27, 2016 at 06:39:23PM +0000, Will Deacon wrote:

quoted

On Wed, Jan 27, 2016 at 07:25:51PM +0100, Peter Zijlstra wrote:

quoted

On Wed, Jan 27, 2016 at 06:22:04PM +0000, Will Deacon wrote:

quoted

As much as we'd like to live in a world where RELEASE -> ACQUIRE is
always cheaply ordered and can be used to construct UNLOCK -> LOCK
definitions with similar guarantees, the grim reality is that this isn't
even possible on x86 (thanks to Paul for bringing us crashing down to
Earth).

This patch handles the issue by introducing a new barrier macro,
smp_mb__after_release_acquire, that can be placed after an ACQUIRE that
either reads from a RELEASE or is in program-order after a RELEASE. The
barrier upgrades the RELEASE-ACQUIRE pair to a full memory barrier,
implying global transitivity. At the moment, it doesn't have any users,
so its existence serves mainly as a documentation aid and a potential
stepping stone to the reintroduction of smp_mb__after_unlock_lock() used
by RCU.

Documentation/memory-barriers.txt is updated to describe more clearly
the ACQUIRE and RELEASE ordering in this area and to show some examples
of the new barrier in action.

So the obvious question is: do we have a use-case?

We have a use-case for smp_mb__after_unlock_lock, so I think we should
either strengthen our locking guarantees so that smp_mb__after_unlock_lock
isn't needed or introduce smp_mb__after_release_acquire to close the gap.
As it stands, we've got an inconsistency (despite it being hidden inside
RCU).

The main advantage of this patch is a documentation aid, in my opinion
(hell, we talk about smp_mb__after_unlock_lock already when reasoning
about this stuff).

But wasn't there an x86 potential use case that required placing the
strengthening macro after the release and before the acquire?  Or is
this a case of old age striking again?

The proposal here doesn't order the release/acquire operations with each
other -- it just says that they combine with smp_mb__after_release_acquire()
to make a full barrier, so I don't think it should matter for the
intra-thread case, which is the one that x86 cares out iiuc.

Will