From: tip-bot for Mark Rutland <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: parri.andrea@gmail.com, tglx@linutronix.de, hpa@zytor.com,
boqun.feng@gmail.com, torvalds@linux-foundation.org,
mingo@kernel.org, mark.rutland@arm.com, will.deacon@arm.com,
linux-kernel@vger.kernel.org, peterz@infradead.org
Subject: [tip:locking/core] locking/atomics: Rework ordering barriers
Date: Wed, 25 Jul 2018 07:36:08 -0700 [thread overview]
Message-ID: <tip-fd2efaa4eb5317c3a86357a83a7d456a1b86a0ac@git.kernel.org> (raw)
In-Reply-To: <20180716113017.3909-7-mark.rutland@arm.com>
Commit-ID: fd2efaa4eb5317c3a86357a83a7d456a1b86a0ac
Gitweb: https://git.kernel.org/tip/fd2efaa4eb5317c3a86357a83a7d456a1b86a0ac
Author: Mark Rutland <mark.rutland@arm.com>
AuthorDate: Mon, 16 Jul 2018 12:30:11 +0100
Committer: Ingo Molnar <mingo@kernel.org>
CommitDate: Wed, 25 Jul 2018 11:53:59 +0200
locking/atomics: Rework ordering barriers
Currently architectures can override __atomic_op_*() to define the barriers
used before/after a relaxed atomic when used to build acquire/release/fence
variants.
This has the unfortunate property of requiring the architecture to define the
full wrapper for the atomics, rather than just the barriers they care about,
and gets in the way of generating atomics which can be easily read.
Instead, this patch has architectures define an optional set of barriers:
* __atomic_acquire_fence()
* __atomic_release_fence()
* __atomic_pre_full_fence()
* __atomic_post_full_fence()
... which <linux/atomic.h> uses to build the wrappers.
It would be nice if we could undef these, along with the __atomic_op_*()
wrappers, but that would break the cmpxchg() wrappers, which are written
in preprocessor. Undefs would have been nice, but alas.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Andrea Parri <parri.andrea@gmail.com>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: andy.shevchenko@gmail.com
Cc: arnd@arndb.de
Cc: aryabinin@virtuozzo.com
Cc: catalin.marinas@arm.com
Cc: dvyukov@google.com
Cc: glider@google.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: peter@hurleysoftware.com
Link: http://lkml.kernel.org/r/20180716113017.3909-7-mark.rutland@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
arch/alpha/include/asm/atomic.h | 8 ++++----
arch/powerpc/include/asm/atomic.h | 17 +++++------------
arch/riscv/include/asm/atomic.h | 17 +++++------------
include/linux/atomic.h | 38 ++++++++++++++++++++++----------------
4 files changed, 36 insertions(+), 44 deletions(-)
diff --git a/arch/alpha/include/asm/atomic.h b/arch/alpha/include/asm/atomic.h
index 4a6a8f58c9c9..150a1c5d6a2c 100644
--- a/arch/alpha/include/asm/atomic.h
+++ b/arch/alpha/include/asm/atomic.h
@@ -18,11 +18,11 @@
* To ensure dependency ordering is preserved for the _relaxed and
* _release atomics, an smp_read_barrier_depends() is unconditionally
* inserted into the _relaxed variants, which are used to build the
- * barriered versions. To avoid redundant back-to-back fences, we can
- * define the _acquire and _fence versions explicitly.
+ * barriered versions. Avoid redundant back-to-back fences in the
+ * _acquire and _fence versions.
*/
-#define __atomic_op_acquire(op, args...) op##_relaxed(args)
-#define __atomic_op_fence __atomic_op_release
+#define __atomic_acquire_fence()
+#define __atomic_post_full_fence()
#define ATOMIC_INIT(i) { (i) }
#define ATOMIC64_INIT(i) { (i) }
diff --git a/arch/powerpc/include/asm/atomic.h b/arch/powerpc/include/asm/atomic.h
index a0156cb43d1f..963abf8bf1c0 100644
--- a/arch/powerpc/include/asm/atomic.h
+++ b/arch/powerpc/include/asm/atomic.h
@@ -18,18 +18,11 @@
* a "bne-" instruction at the end, so an isync is enough as a acquire barrier
* on the platform without lwsync.
*/
-#define __atomic_op_acquire(op, args...) \
-({ \
- typeof(op##_relaxed(args)) __ret = op##_relaxed(args); \
- __asm__ __volatile__(PPC_ACQUIRE_BARRIER "" : : : "memory"); \
- __ret; \
-})
-
-#define __atomic_op_release(op, args...) \
-({ \
- __asm__ __volatile__(PPC_RELEASE_BARRIER "" : : : "memory"); \
- op##_relaxed(args); \
-})
+#define __atomic_acquire_fence() \
+ __asm__ __volatile__(PPC_ACQUIRE_BARRIER "" : : : "memory")
+
+#define __atomic_release_fence() \
+ __asm__ __volatile__(PPC_RELEASE_BARRIER "" : : : "memory")
static __inline__ int atomic_read(const atomic_t *v)
{
diff --git a/arch/riscv/include/asm/atomic.h b/arch/riscv/include/asm/atomic.h
index 512b89485790..c452359c9cb8 100644
--- a/arch/riscv/include/asm/atomic.h
+++ b/arch/riscv/include/asm/atomic.h
@@ -25,18 +25,11 @@
#define ATOMIC_INIT(i) { (i) }
-#define __atomic_op_acquire(op, args...) \
-({ \
- typeof(op##_relaxed(args)) __ret = op##_relaxed(args); \
- __asm__ __volatile__(RISCV_ACQUIRE_BARRIER "" ::: "memory"); \
- __ret; \
-})
-
-#define __atomic_op_release(op, args...) \
-({ \
- __asm__ __volatile__(RISCV_RELEASE_BARRIER "" ::: "memory"); \
- op##_relaxed(args); \
-})
+#define __atomic_acquire_fence() \
+ __asm__ __volatile__(RISCV_ACQUIRE_BARRIER "" ::: "memory")
+
+#define __atomic_release_fence() \
+ __asm__ __volatile__(RISCV_RELEASE_BARRIER "" ::: "memory");
static __always_inline int atomic_read(const atomic_t *v)
{
diff --git a/include/linux/atomic.h b/include/linux/atomic.h
index 8e04f1f69bd9..1e8e88bdaf09 100644
--- a/include/linux/atomic.h
+++ b/include/linux/atomic.h
@@ -38,40 +38,46 @@
* barriers on top of the relaxed variant. In the case where the relaxed
* variant is already fully ordered, no additional barriers are needed.
*
- * Besides, if an arch has a special barrier for acquire/release, it could
- * implement its own __atomic_op_* and use the same framework for building
- * variants
- *
- * If an architecture overrides __atomic_op_acquire() it will probably want
- * to define smp_mb__after_spinlock().
+ * If an architecture overrides __atomic_acquire_fence() it will probably
+ * want to define smp_mb__after_spinlock().
*/
-#ifndef __atomic_op_acquire
+#ifndef __atomic_acquire_fence
+#define __atomic_acquire_fence smp_mb__after_atomic
+#endif
+
+#ifndef __atomic_release_fence
+#define __atomic_release_fence smp_mb__before_atomic
+#endif
+
+#ifndef __atomic_pre_full_fence
+#define __atomic_pre_full_fence smp_mb__before_atomic
+#endif
+
+#ifndef __atomic_post_full_fence
+#define __atomic_post_full_fence smp_mb__after_atomic
+#endif
+
#define __atomic_op_acquire(op, args...) \
({ \
typeof(op##_relaxed(args)) __ret = op##_relaxed(args); \
- smp_mb__after_atomic(); \
+ __atomic_acquire_fence(); \
__ret; \
})
-#endif
-#ifndef __atomic_op_release
#define __atomic_op_release(op, args...) \
({ \
- smp_mb__before_atomic(); \
+ __atomic_release_fence(); \
op##_relaxed(args); \
})
-#endif
-#ifndef __atomic_op_fence
#define __atomic_op_fence(op, args...) \
({ \
typeof(op##_relaxed(args)) __ret; \
- smp_mb__before_atomic(); \
+ __atomic_pre_full_fence(); \
__ret = op##_relaxed(args); \
- smp_mb__after_atomic(); \
+ __atomic_post_full_fence(); \
__ret; \
})
-#endif
/* atomic_add_return_relaxed */
#ifndef atomic_add_return_relaxed
next prev parent reply other threads:[~2018-07-25 14:36 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-16 11:30 [PATCHv4 00/12] atomics: generate atomic headers / instrument arm64 Mark Rutland
2018-07-16 11:30 ` [PATCHv4 01/12] atomic/tty: Fix up atomic abuse in ldsem Mark Rutland
2018-07-24 7:15 ` Ingo Molnar
2018-07-24 9:20 ` Peter Zijlstra
2018-07-24 9:23 ` Mark Rutland
2018-07-24 11:13 ` Ingo Molnar
2018-07-24 13:05 ` Mark Rutland
2018-07-24 13:40 ` Ingo Molnar
2018-07-24 15:06 ` Mark Rutland
2018-07-16 11:30 ` [PATCHv4 02/12] atomics/x86: reduce arch_cmpxchg64*() instrumentation Mark Rutland
2018-07-16 19:23 ` Thomas Gleixner
2018-07-25 14:34 ` [tip:locking/core] locking/atomics/x86: Reduce " tip-bot for Mark Rutland
2018-07-16 11:30 ` [PATCHv4 03/12] atomics: simplify cmpxchg() instrumentation Mark Rutland
2018-07-25 14:34 ` [tip:locking/core] locking/atomics: Simplify " tip-bot for Mark Rutland
2018-07-16 11:30 ` [PATCHv4 04/12] atomics/treewide: instrument xchg() Mark Rutland
2018-07-25 14:35 ` [tip:locking/core] locking/atomics: Instrument xchg() tip-bot for Mark Rutland
2018-07-16 11:30 ` [PATCHv4 05/12] atomics: instrument cmpxchg_double*() Mark Rutland
2018-07-25 14:35 ` [tip:locking/core] locking/atomics: Instrument cmpxchg_double*() tip-bot for Mark Rutland
2018-07-16 11:30 ` [PATCHv4 06/12] atomics/treewide: rework ordering barriers Mark Rutland
2018-07-25 14:36 ` tip-bot for Mark Rutland [this message]
2018-07-16 11:30 ` [PATCHv4 07/12] atomics: add common header generation files Mark Rutland
2018-07-16 11:30 ` [PATCHv4 08/12] atomics: switch to generated fallbacks Mark Rutland
2018-07-16 11:30 ` [PATCHv4 09/12] atomics: switch to generated atomic-long Mark Rutland
2018-07-16 11:30 ` [PATCHv4 10/12] atomics: switch to generated instrumentation Mark Rutland
2018-07-16 11:30 ` [PATCHv4 11/12] atomics: check generated headers are up-to-date Mark Rutland
2018-07-16 11:30 ` [PATCHv4 12/12] arm64: use instrumented atomics Mark Rutland
2018-07-23 9:57 ` [PATCHv4 00/12] atomics: generate atomic headers / instrument arm64 Mark Rutland
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=tip-fd2efaa4eb5317c3a86357a83a7d456a1b86a0ac@git.kernel.org \
--to=tipbot@zytor.com \
--cc=boqun.feng@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=parri.andrea@gmail.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome