From: Will Deacon <will@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: Will Deacon <will@kernel.org>, Joel Fernandes <joelaf@google.com>,
Sami Tolvanen <samitolvanen@google.com>,
Nick Desaulniers <ndesaulniers@google.com>,
Kees Cook <keescook@chromium.org>, Marco Elver <elver@google.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
Matt Turner <mattst88@gmail.com>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Richard Henderson <rth@twiddle.net>,
Peter Zijlstra <peterz@infradead.org>,
Alan Stern <stern@rowland.harvard.edu>,
"Michael S. Tsirkin" <mst@redhat.com>,
Jason Wang <jasowang@redhat.com>, Arnd Bergmann <arnd@arndb.de>,
Boqun Feng <boqun.feng@gmail.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-alpha@vger.kernel.org, virtualizati
Subject: [PATCH v3 04/19] alpha: Override READ_ONCE() with barriered implementation
Date: Fri, 10 Jul 2020 17:51:48 +0100 [thread overview]
Message-ID: <20200710165203.31284-5-will@kernel.org> (raw)
In-Reply-To: <20200710165203.31284-1-will@kernel.org>
Rather then relying on the core code to use smp_read_barrier_depends()
as part of the READ_ONCE() definition, instead override __READ_ONCE()
in the Alpha code so that it generates the required mb() and then
implement smp_load_acquire() using the new macro to avoid redundant
back-to-back barriers from the generic implementation.
Acked-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/alpha/include/asm/barrier.h | 59 +++-----------------------------
arch/alpha/include/asm/rwonce.h | 35 +++++++++++++++++++
2 files changed, 40 insertions(+), 54 deletions(-)
create mode 100644 arch/alpha/include/asm/rwonce.h
diff --git a/arch/alpha/include/asm/barrier.h b/arch/alpha/include/asm/barrier.h
index 92ec486a4f9e..c56bfffc9918 100644
--- a/arch/alpha/include/asm/barrier.h
+++ b/arch/alpha/include/asm/barrier.h
@@ -2,64 +2,15 @@
#ifndef __BARRIER_H
#define __BARRIER_H
-#include <asm/compiler.h>
-
#define mb() __asm__ __volatile__("mb": : :"memory")
#define rmb() __asm__ __volatile__("mb": : :"memory")
#define wmb() __asm__ __volatile__("wmb": : :"memory")
-/**
- * read_barrier_depends - Flush all pending reads that subsequents reads
- * depend on.
- *
- * No data-dependent reads from memory-like regions are ever reordered
- * over this barrier. All reads preceding this primitive are guaranteed
- * to access memory (but not necessarily other CPUs' caches) before any
- * reads following this primitive that depend on the data return by
- * any of the preceding reads. This primitive is much lighter weight than
- * rmb() on most CPUs, and is never heavier weight than is
- * rmb().
- *
- * These ordering constraints are respected by both the local CPU
- * and the compiler.
- *
- * Ordering is not guaranteed by anything other than these primitives,
- * not even by data dependencies. See the documentation for
- * memory_barrier() for examples and URLs to more information.
- *
- * For example, the following code would force ordering (the initial
- * value of "a" is zero, "b" is one, and "p" is "&a"):
- *
- * <programlisting>
- * CPU 0 CPU 1
- *
- * b = 2;
- * memory_barrier();
- * p = &b; q = p;
- * read_barrier_depends();
- * d = *q;
- * </programlisting>
- *
- * because the read of "*q" depends on the read of "p" and these
- * two reads are separated by a read_barrier_depends(). However,
- * the following code, with the same initial values for "a" and "b":
- *
- * <programlisting>
- * CPU 0 CPU 1
- *
- * a = 2;
- * memory_barrier();
- * b = 3; y = b;
- * read_barrier_depends();
- * x = a;
- * </programlisting>
- *
- * does not enforce ordering, since there is no data dependency between
- * the read of "a" and the read of "b". Therefore, on some CPUs, such
- * as Alpha, "y" could be set to 3 and "x" to 0. Use rmb()
- * in cases like this where there are no data dependencies.
- */
-#define read_barrier_depends() __asm__ __volatile__("mb": : :"memory")
+#define __smp_load_acquire(p) \
+({ \
+ compiletime_assert_atomic_type(*p); \
+ __READ_ONCE(*p); \
+})
#ifdef CONFIG_SMP
#define __ASM_SMP_MB "\tmb\n"
diff --git a/arch/alpha/include/asm/rwonce.h b/arch/alpha/include/asm/rwonce.h
new file mode 100644
index 000000000000..35542bcf92b3
--- /dev/null
+++ b/arch/alpha/include/asm/rwonce.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019 Google LLC.
+ */
+#ifndef __ASM_RWONCE_H
+#define __ASM_RWONCE_H
+
+#ifdef CONFIG_SMP
+
+#include <asm/barrier.h>
+
+/*
+ * Alpha is apparently daft enough to reorder address-dependent loads
+ * on some CPU implementations. Knock some common sense into it with
+ * a memory barrier in READ_ONCE().
+ *
+ * For the curious, more information about this unusual reordering is
+ * available in chapter 15 of the "perfbook":
+ *
+ * https://kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html
+ *
+ */
+#define __READ_ONCE(x) \
+({ \
+ __unqual_scalar_typeof(x) __x = \
+ (*(volatile typeof(__x) *)(&(x))); \
+ mb(); \
+ (typeof(x))__x; \
+})
+
+#endif /* CONFIG_SMP */
+
+#include <asm-generic/rwonce.h>
+
+#endif /* __ASM_RWONCE_H */
--
2.27.0.383.g050319c2ae-goog
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: Joel Fernandes <joelaf@google.com>,
Mark Rutland <mark.rutland@arm.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Jason Wang <jasowang@redhat.com>,
virtualization@lists.linux-foundation.org,
Will Deacon <will@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Alan Stern <stern@rowland.harvard.edu>,
Sami Tolvanen <samitolvanen@google.com>,
Matt Turner <mattst88@gmail.com>,
kernel-team@android.com, Marco Elver <elver@google.com>,
Kees Cook <keescook@chromium.org>,
"Paul E. McKenney" <paulmck@kernel.org>,
Boqun Feng <boqun.feng@gmail.com>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
linux-arm-kernel@lists.infradead.org,
Richard Henderson <rth@twiddle.net>,
Nick Desaulniers <ndesaulniers@google.com>,
linux-alpha@vger.kernel.org
Subject: [PATCH v3 04/19] alpha: Override READ_ONCE() with barriered implementation
Date: Fri, 10 Jul 2020 17:51:48 +0100 [thread overview]
Message-ID: <20200710165203.31284-5-will@kernel.org> (raw)
In-Reply-To: <20200710165203.31284-1-will@kernel.org>
Rather then relying on the core code to use smp_read_barrier_depends()
as part of the READ_ONCE() definition, instead override __READ_ONCE()
in the Alpha code so that it generates the required mb() and then
implement smp_load_acquire() using the new macro to avoid redundant
back-to-back barriers from the generic implementation.
Acked-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/alpha/include/asm/barrier.h | 59 +++-----------------------------
arch/alpha/include/asm/rwonce.h | 35 +++++++++++++++++++
2 files changed, 40 insertions(+), 54 deletions(-)
create mode 100644 arch/alpha/include/asm/rwonce.h
diff --git a/arch/alpha/include/asm/barrier.h b/arch/alpha/include/asm/barrier.h
index 92ec486a4f9e..c56bfffc9918 100644
--- a/arch/alpha/include/asm/barrier.h
+++ b/arch/alpha/include/asm/barrier.h
@@ -2,64 +2,15 @@
#ifndef __BARRIER_H
#define __BARRIER_H
-#include <asm/compiler.h>
-
#define mb() __asm__ __volatile__("mb": : :"memory")
#define rmb() __asm__ __volatile__("mb": : :"memory")
#define wmb() __asm__ __volatile__("wmb": : :"memory")
-/**
- * read_barrier_depends - Flush all pending reads that subsequents reads
- * depend on.
- *
- * No data-dependent reads from memory-like regions are ever reordered
- * over this barrier. All reads preceding this primitive are guaranteed
- * to access memory (but not necessarily other CPUs' caches) before any
- * reads following this primitive that depend on the data return by
- * any of the preceding reads. This primitive is much lighter weight than
- * rmb() on most CPUs, and is never heavier weight than is
- * rmb().
- *
- * These ordering constraints are respected by both the local CPU
- * and the compiler.
- *
- * Ordering is not guaranteed by anything other than these primitives,
- * not even by data dependencies. See the documentation for
- * memory_barrier() for examples and URLs to more information.
- *
- * For example, the following code would force ordering (the initial
- * value of "a" is zero, "b" is one, and "p" is "&a"):
- *
- * <programlisting>
- * CPU 0 CPU 1
- *
- * b = 2;
- * memory_barrier();
- * p = &b; q = p;
- * read_barrier_depends();
- * d = *q;
- * </programlisting>
- *
- * because the read of "*q" depends on the read of "p" and these
- * two reads are separated by a read_barrier_depends(). However,
- * the following code, with the same initial values for "a" and "b":
- *
- * <programlisting>
- * CPU 0 CPU 1
- *
- * a = 2;
- * memory_barrier();
- * b = 3; y = b;
- * read_barrier_depends();
- * x = a;
- * </programlisting>
- *
- * does not enforce ordering, since there is no data dependency between
- * the read of "a" and the read of "b". Therefore, on some CPUs, such
- * as Alpha, "y" could be set to 3 and "x" to 0. Use rmb()
- * in cases like this where there are no data dependencies.
- */
-#define read_barrier_depends() __asm__ __volatile__("mb": : :"memory")
+#define __smp_load_acquire(p) \
+({ \
+ compiletime_assert_atomic_type(*p); \
+ __READ_ONCE(*p); \
+})
#ifdef CONFIG_SMP
#define __ASM_SMP_MB "\tmb\n"
diff --git a/arch/alpha/include/asm/rwonce.h b/arch/alpha/include/asm/rwonce.h
new file mode 100644
index 000000000000..35542bcf92b3
--- /dev/null
+++ b/arch/alpha/include/asm/rwonce.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019 Google LLC.
+ */
+#ifndef __ASM_RWONCE_H
+#define __ASM_RWONCE_H
+
+#ifdef CONFIG_SMP
+
+#include <asm/barrier.h>
+
+/*
+ * Alpha is apparently daft enough to reorder address-dependent loads
+ * on some CPU implementations. Knock some common sense into it with
+ * a memory barrier in READ_ONCE().
+ *
+ * For the curious, more information about this unusual reordering is
+ * available in chapter 15 of the "perfbook":
+ *
+ * https://kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html
+ *
+ */
+#define __READ_ONCE(x) \
+({ \
+ __unqual_scalar_typeof(x) __x = \
+ (*(volatile typeof(__x) *)(&(x))); \
+ mb(); \
+ (typeof(x))__x; \
+})
+
+#endif /* CONFIG_SMP */
+
+#include <asm-generic/rwonce.h>
+
+#endif /* __ASM_RWONCE_H */
--
2.27.0.383.g050319c2ae-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: Will Deacon <will@kernel.org>, Joel Fernandes <joelaf@google.com>,
Sami Tolvanen <samitolvanen@google.com>,
Nick Desaulniers <ndesaulniers@google.com>,
Kees Cook <keescook@chromium.org>, Marco Elver <elver@google.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
Matt Turner <mattst88@gmail.com>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Richard Henderson <rth@twiddle.net>,
Peter Zijlstra <peterz@infradead.org>,
Alan Stern <stern@rowland.harvard.edu>,
"Michael S. Tsirkin" <mst@redhat.com>,
Jason Wang <jasowang@redhat.com>, Arnd Bergmann <arnd@arndb.de>,
Boqun Feng <boqun.feng@gmail.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-alpha@vger.kernel.org,
virtualization@lists.linux-foundation.org,
kernel-team@android.com
Subject: [PATCH v3 04/19] alpha: Override READ_ONCE() with barriered implementation
Date: Fri, 10 Jul 2020 17:51:48 +0100 [thread overview]
Message-ID: <20200710165203.31284-5-will@kernel.org> (raw)
In-Reply-To: <20200710165203.31284-1-will@kernel.org>
Rather then relying on the core code to use smp_read_barrier_depends()
as part of the READ_ONCE() definition, instead override __READ_ONCE()
in the Alpha code so that it generates the required mb() and then
implement smp_load_acquire() using the new macro to avoid redundant
back-to-back barriers from the generic implementation.
Acked-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/alpha/include/asm/barrier.h | 59 +++-----------------------------
arch/alpha/include/asm/rwonce.h | 35 +++++++++++++++++++
2 files changed, 40 insertions(+), 54 deletions(-)
create mode 100644 arch/alpha/include/asm/rwonce.h
diff --git a/arch/alpha/include/asm/barrier.h b/arch/alpha/include/asm/barrier.h
index 92ec486a4f9e..c56bfffc9918 100644
--- a/arch/alpha/include/asm/barrier.h
+++ b/arch/alpha/include/asm/barrier.h
@@ -2,64 +2,15 @@
#ifndef __BARRIER_H
#define __BARRIER_H
-#include <asm/compiler.h>
-
#define mb() __asm__ __volatile__("mb": : :"memory")
#define rmb() __asm__ __volatile__("mb": : :"memory")
#define wmb() __asm__ __volatile__("wmb": : :"memory")
-/**
- * read_barrier_depends - Flush all pending reads that subsequents reads
- * depend on.
- *
- * No data-dependent reads from memory-like regions are ever reordered
- * over this barrier. All reads preceding this primitive are guaranteed
- * to access memory (but not necessarily other CPUs' caches) before any
- * reads following this primitive that depend on the data return by
- * any of the preceding reads. This primitive is much lighter weight than
- * rmb() on most CPUs, and is never heavier weight than is
- * rmb().
- *
- * These ordering constraints are respected by both the local CPU
- * and the compiler.
- *
- * Ordering is not guaranteed by anything other than these primitives,
- * not even by data dependencies. See the documentation for
- * memory_barrier() for examples and URLs to more information.
- *
- * For example, the following code would force ordering (the initial
- * value of "a" is zero, "b" is one, and "p" is "&a"):
- *
- * <programlisting>
- * CPU 0 CPU 1
- *
- * b = 2;
- * memory_barrier();
- * p = &b; q = p;
- * read_barrier_depends();
- * d = *q;
- * </programlisting>
- *
- * because the read of "*q" depends on the read of "p" and these
- * two reads are separated by a read_barrier_depends(). However,
- * the following code, with the same initial values for "a" and "b":
- *
- * <programlisting>
- * CPU 0 CPU 1
- *
- * a = 2;
- * memory_barrier();
- * b = 3; y = b;
- * read_barrier_depends();
- * x = a;
- * </programlisting>
- *
- * does not enforce ordering, since there is no data dependency between
- * the read of "a" and the read of "b". Therefore, on some CPUs, such
- * as Alpha, "y" could be set to 3 and "x" to 0. Use rmb()
- * in cases like this where there are no data dependencies.
- */
-#define read_barrier_depends() __asm__ __volatile__("mb": : :"memory")
+#define __smp_load_acquire(p) \
+({ \
+ compiletime_assert_atomic_type(*p); \
+ __READ_ONCE(*p); \
+})
#ifdef CONFIG_SMP
#define __ASM_SMP_MB "\tmb\n"
diff --git a/arch/alpha/include/asm/rwonce.h b/arch/alpha/include/asm/rwonce.h
new file mode 100644
index 000000000000..35542bcf92b3
--- /dev/null
+++ b/arch/alpha/include/asm/rwonce.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019 Google LLC.
+ */
+#ifndef __ASM_RWONCE_H
+#define __ASM_RWONCE_H
+
+#ifdef CONFIG_SMP
+
+#include <asm/barrier.h>
+
+/*
+ * Alpha is apparently daft enough to reorder address-dependent loads
+ * on some CPU implementations. Knock some common sense into it with
+ * a memory barrier in READ_ONCE().
+ *
+ * For the curious, more information about this unusual reordering is
+ * available in chapter 15 of the "perfbook":
+ *
+ * https://kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html
+ *
+ */
+#define __READ_ONCE(x) \
+({ \
+ __unqual_scalar_typeof(x) __x = \
+ (*(volatile typeof(__x) *)(&(x))); \
+ mb(); \
+ (typeof(x))__x; \
+})
+
+#endif /* CONFIG_SMP */
+
+#include <asm-generic/rwonce.h>
+
+#endif /* __ASM_RWONCE_H */
--
2.27.0.383.g050319c2ae-goog
next prev parent reply other threads:[~2020-07-10 16:51 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-10 16:51 [PATCH 00/18] Allow architectures to override __READ_ONCE() Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` [PATCH v3 01/19] tools: bpf: Use local copy of headers including uapi/linux/filter.h Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` [PATCH v3 02/19] compiler.h: Split {READ,WRITE}_ONCE definitions out into rwonce.h Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` [PATCH v3 02/19] compiler.h: Split {READ, WRITE}_ONCE " Will Deacon
2020-07-13 12:23 ` [PATCH v3 02/19] compiler.h: Split {READ,WRITE}_ONCE " boqun.feng
2020-07-13 12:23 ` boqun.feng
2020-07-13 12:23 ` [PATCH v3 02/19] compiler.h: Split {READ, WRITE}_ONCE " boqun.feng
2020-07-20 15:55 ` Will Deacon
2020-07-20 15:55 ` [PATCH v3 02/19] compiler.h: Split {READ,WRITE}_ONCE " Will Deacon
2020-07-20 15:55 ` [PATCH v3 02/19] compiler.h: Split {READ, WRITE}_ONCE " Will Deacon
2020-07-10 16:51 ` [PATCH v3 03/19] asm/rwonce: Allow __READ_ONCE to be overridden by the architecture Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` Will Deacon [this message]
2020-07-10 16:51 ` [PATCH v3 04/19] alpha: Override READ_ONCE() with barriered implementation Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` [PATCH v3 05/19] asm/rwonce: Remove smp_read_barrier_depends() invocation Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` [PATCH v3 06/19] asm/rwonce: Don't pull <asm/barrier.h> into 'asm-generic/rwonce.h' Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 17:06 ` Nick Desaulniers
2020-07-10 17:06 ` Nick Desaulniers
2020-07-10 17:06 ` Nick Desaulniers
2020-07-10 17:15 ` Will Deacon
2020-07-10 17:15 ` Will Deacon
2020-07-10 17:15 ` Will Deacon
2020-07-10 16:51 ` [PATCH v3 07/19] vhost: Remove redundant use of read_barrier_depends() barrier Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-13 11:27 ` Michael S. Tsirkin
2020-07-13 11:27 ` Michael S. Tsirkin
2020-07-13 11:27 ` Michael S. Tsirkin
2020-07-10 16:51 ` [PATCH v3 08/19] alpha: Replace smp_read_barrier_depends() usage with smp_[r]mb() Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` [PATCH v3 09/19] locking/barriers: Remove definitions for [smp_]read_barrier_depends() Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` [PATCH v3 10/19] Documentation/barriers: Remove references to [smp_]read_barrier_depends() Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` [PATCH v3 11/19] Documentation/barriers/kokr: " Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` [PATCH v3 12/19] tools/memory-model: Remove smp_read_barrier_depends() from informal doc Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` [PATCH v3 13/19] include/linux: Remove smp_read_barrier_depends() from comments Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` [PATCH v3 14/19] checkpatch: Remove checks relating to [smp_]read_barrier_depends() Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` [PATCH v3 15/19] arm64: Reduce the number of header files pulled into vmlinux.lds.S Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:51 ` Will Deacon
2020-07-10 16:52 ` [PATCH v3 16/19] arm64: alternatives: Split up alternative.h Will Deacon
2020-07-10 16:52 ` Will Deacon
2020-07-10 16:52 ` Will Deacon
2020-07-10 16:52 ` [PATCH v3 17/19] arm64: cpufeatures: Add capability for LDAPR instruction Will Deacon
2020-07-10 16:52 ` Will Deacon
2020-07-10 16:52 ` Will Deacon
2020-07-10 16:52 ` [PATCH v3 18/19] arm64: alternatives: Remove READ_ONCE() usage during patch operation Will Deacon
2020-07-10 16:52 ` Will Deacon
2020-07-10 16:52 ` Will Deacon
2020-07-10 16:52 ` [PATCH v3 19/19] arm64: lto: Strengthen READ_ONCE() to acquire when CONFIG_LTO=y Will Deacon
2020-07-10 16:52 ` Will Deacon
2020-07-10 16:52 ` Will Deacon
2020-07-28 20:40 ` Pavel Machek
2020-07-28 20:40 ` Pavel Machek
2020-07-28 20:40 ` Pavel Machek
2020-07-13 10:34 ` [PATCH 00/18] Allow architectures to override __READ_ONCE() Peter Zijlstra
2020-07-13 10:34 ` Peter Zijlstra
2020-07-13 10:34 ` 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=20200710165203.31284-5-will@kernel.org \
--to=will@kernel.org \
--cc=arnd@arndb.de \
--cc=boqun.feng@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=elver@google.com \
--cc=ink@jurassic.park.msu.ru \
--cc=jasowang@redhat.com \
--cc=joelaf@google.com \
--cc=keescook@chromium.org \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mattst88@gmail.com \
--cc=mst@redhat.com \
--cc=ndesaulniers@google.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rth@twiddle.net \
--cc=samitolvanen@google.com \
--cc=stern@rowland.harvard.edu \
/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.