All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: benh@kernel.crashing.org, Ingo Molnar <mingo@elte.hu>,
	Boqun Feng <boqun.feng@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	1vier1@web.de, Davidlohr Bueso <dave@stgolabs.net>
Subject: Re: [PATCH 2/4] barrier.h: Move smp_mb__after_unlock_lock to barrier.h
Date: Sun, 28 Aug 2016 06:43:22 -0700	[thread overview]
Message-ID: <20160828134321.GC19706@linux.vnet.ibm.com> (raw)
In-Reply-To: <1472385376-8801-3-git-send-email-manfred@colorfullife.com>

On Sun, Aug 28, 2016 at 01:56:14PM +0200, Manfred Spraul wrote:
> spin_unlock() + spin_lock() together do not form a full memory barrier:
> 
>   a=1;
>   spin_unlock(&b);
>   spin_lock(&c);
> + smp_mb__after_unlock_lock();
>   d=1;

Better would be s/d=1/r1=d/ above.

Then another process doing this:

	d=1
	smp_mb()
	r2=a

might have the after-the-dust-settles outcome of r1==0&&r2==0.

The advantage of this scenario is that it can happen on real hardware.

> 
> Without the smp_mb__after_unlock_lock(), other CPUs can observe the
> write to d without seeing the write to a.
> 
> Signed-off-by: Manfred Spraul <manfred@colorfullife.com>

With the upgraded commit log, I am OK with the patch below.
However, others will probably want to see at least one use of
smp_mb__after_unlock_lock() outside of RCU.

							Thanx, Paul

> ---
>  include/asm-generic/barrier.h | 16 ++++++++++++++++
>  kernel/rcu/tree.h             | 12 ------------
>  2 files changed, 16 insertions(+), 12 deletions(-)
> 
> diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h
> index fe297b5..9b4d28f 100644
> --- a/include/asm-generic/barrier.h
> +++ b/include/asm-generic/barrier.h
> @@ -244,6 +244,22 @@ do {									\
>  	smp_acquire__after_ctrl_dep();				\
>  	VAL;							\
>  })
> +
> +#ifndef smp_mb__after_unlock_lock
> +/*
> + * Place this after a lock-acquisition primitive to guarantee that
> + * an UNLOCK+LOCK pair act as a full barrier.  This guarantee applies
> + * if the UNLOCK and LOCK are executed by the same CPU or if the
> + * UNLOCK and LOCK operate on the same lock variable.
> + */
> +#ifdef CONFIG_PPC
> +#define smp_mb__after_unlock_lock()	smp_mb()  /* Full ordering for lock. */
> +#else /* #ifdef CONFIG_PPC */
> +#define smp_mb__after_unlock_lock()	do { } while (0)
> +#endif /* #else #ifdef CONFIG_PPC */
> +
> +#endif
> +
>  #endif
> 
>  #endif /* !__ASSEMBLY__ */
> diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
> index e99a523..a0cd9ab 100644
> --- a/kernel/rcu/tree.h
> +++ b/kernel/rcu/tree.h
> @@ -687,18 +687,6 @@ static inline void rcu_nocb_q_lengths(struct rcu_data *rdp, long *ql, long *qll)
>  #endif /* #ifdef CONFIG_RCU_TRACE */
> 
>  /*
> - * Place this after a lock-acquisition primitive to guarantee that
> - * an UNLOCK+LOCK pair act as a full barrier.  This guarantee applies
> - * if the UNLOCK and LOCK are executed by the same CPU or if the
> - * UNLOCK and LOCK operate on the same lock variable.
> - */
> -#ifdef CONFIG_PPC
> -#define smp_mb__after_unlock_lock()	smp_mb()  /* Full ordering for lock. */
> -#else /* #ifdef CONFIG_PPC */
> -#define smp_mb__after_unlock_lock()	do { } while (0)
> -#endif /* #else #ifdef CONFIG_PPC */
> -
> -/*
>   * Wrappers for the rcu_node::lock acquire and release.
>   *
>   * Because the rcu_nodes form a tree, the tree traversal locking will observe
> -- 
> 2.5.5
> 

  parent reply	other threads:[~2016-08-28 13:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-28 11:56 [PATCH 0/4] Clarify/standardize memory barriers for lock/unlock Manfred Spraul
2016-08-28 11:56 ` [PATCH 1/4] spinlock: Document memory barrier rules Manfred Spraul
2016-08-28 11:56   ` [PATCH 2/4] barrier.h: Move smp_mb__after_unlock_lock to barrier.h Manfred Spraul
2016-08-28 11:56     ` [PATCH 3/4] net/netfilter/nf_conntrack_core: update memory barriers Manfred Spraul
2016-08-28 11:56       ` [PATCH 4/4] qspinlock for x86: smp_mb__after_spin_lock() is free Manfred Spraul
2016-08-29 10:52         ` Peter Zijlstra
2016-08-29 10:51       ` [PATCH 3/4] net/netfilter/nf_conntrack_core: update memory barriers Peter Zijlstra
2016-08-28 13:43     ` Paul E. McKenney [this message]
2016-08-28 16:31       ` [PATCH 2/4] barrier.h: Move smp_mb__after_unlock_lock to barrier.h Manfred Spraul
2016-08-28 18:00       ` Manfred Spraul
2016-08-28 14:41     ` kbuild test robot
2016-08-28 17:43       ` [PATCH 2/4 v3] spinlock.h: Move smp_mb__after_unlock_lock to spinlock.h Manfred Spraul
2016-08-29 10:48   ` [PATCH 1/4] spinlock: Document memory barrier rules Peter Zijlstra
2016-08-29 12:54     ` Manfred Spraul
2016-08-29 13:44       ` Peter Zijlstra
2016-08-31  4:59         ` Manfred Spraul
2016-08-31 15:40           ` Peter Zijlstra
2016-08-31 16:40             ` Will Deacon
2016-08-31 18:32               ` Manfred Spraul
2016-09-01  8:44                 ` Peter Zijlstra
2016-09-01 11:04                   ` Manfred Spraul
2016-09-01 11:19                     ` Will Deacon
2016-09-01 11:51                     ` Peter Zijlstra
2016-09-01 14:05                       ` Boqun Feng
2016-08-29 10:53 ` [PATCH 0/4] Clarify/standardize memory barriers for lock/unlock Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160828134321.GC19706@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=1vier1@web.de \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=boqun.feng@gmail.com \
    --cc=dave@stgolabs.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.