Re: [PATCH 1/4 v4] spinlock: Document memory barrier rules

[Davidlohr Bueso]

On Mon, 29 Aug 2016, Manfred Spraul wrote:

> Right now, the spinlock machinery tries to guarantee barriers even for
> unorthodox locking cases, which ends up as a constant stream of updates
> as the architectures try to support new unorthodox ideas.
>
> The patch proposes to clarify the rules:
> spin_lock is ACQUIRE, spin_unlock is RELEASE.
> spin_unlock_wait is also ACQUIRE.
> Code that needs further guarantees must use appropriate explicit barriers.
>
> Architectures that can implement some barriers for free can define the
> barriers as NOPs.
>
> As the initial step, the patch converts ipc/sem.c to the new defines:
> - With commit 2c6100227116
>  ("locking/qspinlock: Fix spin_unlock_wait() some more"),
>  (and the commits for the other archs), spin_unlock_wait() is an
>  ACQUIRE.
>  Therefore the smp_rmb() after spin_unlock_wait() can be removed.
> - smp_mb__after_spin_lock() instead of a direct smp_mb().
>  This allows that architectures override it with a less expensive
>  barrier if this is sufficient for their hardware/spinlock
>  implementation.
>
> For overriding, the same approach as for smp_mb__before_spin_lock()
> is used: If smp_mb__after_spin_lock is already defined, then it is
> not changed.
>
> Signed-off-by: Manfred Spraul <manfred@xxxxxxxxxxxxxxxx>
> ---
> Documentation/locking/spinlocks.txt |  5 +++++
> include/linux/spinlock.h            | 12 ++++++++++++
> ipc/sem.c                           | 16 +---------------

Preferably this would have been two patches, specially since you
remove the redundant barrier in complexmode_enter(), which is 
kind of mixing core spinlocking and core sysv sems. But anyway,
this will be the patch that we _don't_ backport to stable, right?

Reviewed-by: Davidlohr Bueso <dave@xxxxxxxxxxxx>