From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kerne.org,
geert@linux-m68k.org, torvalds@linux-foundation.org,
VICTORK@il.ibm.com, oleg@redhat.com, anton@samba.org,
benh@kernel.crashing.org, fweisbec@gmail.com,
mathieu.desnoyers@polymtl.ca, michael@ellerman.id.au,
mikey@neuling.org, linux@arm.linux.org.uk,
schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
tony.luck@intel.com, Will Deacon <will.deacon@arm.com>
Subject: Re: [PATCH 4/4] arch: Introduce smp_load_acquire(), smp_store_release()
Date: Mon, 16 Dec 2013 13:37:20 -0800 [thread overview]
Message-ID: <20131216213720.GA28557@linux.vnet.ibm.com> (raw)
In-Reply-To: <20131213150640.908486364@infradead.org>
On Fri, Dec 13, 2013 at 03:57:01PM +0100, Peter Zijlstra wrote:
> A number of situations currently require the heavyweight smp_mb(),
> even though there is no need to order prior stores against later
> loads. Many architectures have much cheaper ways to handle these
> situations, but the Linux kernel currently has no portable way
> to make use of them.
>
> This commit therefore supplies smp_load_acquire() and
> smp_store_release() to remedy this situation. The new
> smp_load_acquire() primitive orders the specified load against
> any subsequent reads or writes, while the new smp_store_release()
> primitive orders the specifed store against any prior reads or
> writes. These primitives allow array-based circular FIFOs to be
> implemented without an smp_mb(), and also allow a theoretical
> hole in rcu_assign_pointer() to be closed at no additional
> expense on most architectures.
>
> In addition, the RCU experience transitioning from explicit
> smp_read_barrier_depends() and smp_wmb() to rcu_dereference()
> and rcu_assign_pointer(), respectively resulted in substantial
> improvements in readability. It therefore seems likely that
> replacing other explicit barriers with smp_load_acquire() and
> smp_store_release() will provide similar benefits. It appears
> that roughly half of the explicit barriers in core kernel code
> might be so replaced.
And here is an RFC patch switching rcu_assign_pointer() from
smp_wmb() to smp_store_release(). Thoughts?
Thanx, Paul
------------------------------------------------------------------------
rcu: Define rcu_assign_pointer() in terms of smp_store_release()
The new smp_store_release() function provides better guarantees than did
rcu_assign_pointer(), and potentially less overhead on some architectures.
The guarantee that smp_store_release() provides that rcu_assign_pointer()
does that is obscure, but its lack could cause considerable confusion.
This guarantee is illustrated by the following code fragment:
struct foo {
int a;
int b;
int c;
struct foo *next;
};
struct foo foo1;
struct foo foo2;
struct foo __rcu *foop;
...
foo2.a = 1;
foo2.b = 2;
BUG_ON(foo2.c);
rcu_assign_pointer(foop, &foo);
...
fp = rcu_dereference(foop);
fp.c = 3;
The current rcu_assign_pointer() semantics permit the BUG_ON() to
trigger because rcu_assign_pointer()'s smp_wmb() is not guaranteed to
order prior reads against later writes. This commit therefore upgrades
rcu_assign_pointer() from smp_wmb() to smp_store_release() to avoid this
counter-intuitive outcome.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index ad5258cc051b..2fe509171e21 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -582,11 +582,7 @@ static inline void rcu_preempt_sleep_check(void)
* please be careful when making changes to rcu_assign_pointer() and the
* other macros that it invokes.
*/
-#define rcu_assign_pointer(p, v) \
- do { \
- smp_wmb(); \
- ACCESS_ONCE(p) = RCU_INITIALIZER(v); \
- } while (0)
+#define rcu_assign_pointer(p, v) smp_store_release(&p, RCU_INITIALIZER(v));
/**
next prev parent reply other threads:[~2013-12-16 21:37 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-13 14:56 [PATCH 0/4] arch: Introduce smp_load_acquire() and smp_store_release() Peter Zijlstra
2013-12-13 14:56 ` [PATCH 1/4] doc: Rename LOCK/UNLOCK to ACQUIRE/RELEASE Peter Zijlstra
2013-12-16 20:11 ` Paul E. McKenney
2013-12-17 9:24 ` Peter Zijlstra
2013-12-17 15:31 ` Paul E. McKenney
2014-01-12 18:43 ` [tip:core/locking] locking/doc: Rename LOCK/UNLOCK to ACQUIRE/ RELEASE tip-bot for Peter Zijlstra
2013-12-17 10:13 ` [PATCH 1/4] doc: Rename LOCK/UNLOCK to ACQUIRE/RELEASE Peter Zijlstra
2013-12-17 13:59 ` Paul E. McKenney
2013-12-13 14:56 ` [PATCH 2/4] arch: Move smp_mb__{before,after}_atomic_{inc,dec}.h into asm/atomic.h Peter Zijlstra
2013-12-16 20:13 ` Paul E. McKenney
2013-12-18 13:40 ` Vineet Gupta
2014-01-12 18:43 ` [tip:core/locking] arch: Move smp_mb__{before,after}_atomic_{inc, dec}.h " tip-bot for Peter Zijlstra
2013-12-13 14:57 ` [PATCH 3/4] arch: Clean up asm/barrier.h implementations using asm-generic/barrier.h Peter Zijlstra
2013-12-13 19:16 ` Geert Uytterhoeven
2013-12-13 19:17 ` Fwd: " Geert Uytterhoeven
2013-12-13 19:53 ` Peter Zijlstra
2013-12-16 20:14 ` Paul E. McKenney
2014-01-12 18:43 ` [tip:core/locking] arch: Clean up asm/ barrier.h " tip-bot for Peter Zijlstra
2013-12-13 14:57 ` [PATCH 4/4] arch: Introduce smp_load_acquire(), smp_store_release() Peter Zijlstra
2013-12-16 16:40 ` Will Deacon
2013-12-17 9:07 ` Peter Zijlstra
2013-12-16 21:37 ` Paul E. McKenney [this message]
2013-12-17 9:14 ` Peter Zijlstra
2013-12-17 13:58 ` Paul E. McKenney
2014-01-12 18:43 ` [tip:core/locking] " tip-bot for Peter Zijlstra
-- strict thread matches above, loose matches on Subject: below --
2013-12-18 19:08 [PATCH 0/4] arch: Introduce smp_load_acquire() and smp_store_release() Peter Zijlstra
2013-12-18 19:08 ` [PATCH 4/4] arch: Introduce smp_load_acquire(), smp_store_release() 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=20131216213720.GA28557@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=VICTORK@il.ibm.com \
--cc=anton@samba.org \
--cc=benh@kernel.crashing.org \
--cc=fweisbec@gmail.com \
--cc=geert@linux-m68k.org \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kerne.org \
--cc=linux@arm.linux.org.uk \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=michael@ellerman.id.au \
--cc=mikey@neuling.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=schwidefsky@de.ibm.com \
--cc=tony.luck@intel.com \
--cc=torvalds@linux-foundation.org \
--cc=will.deacon@arm.com \
/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.