[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20191016083959.186860-6-elver@google.com>
Date: Wed, 16 Oct 2019 10:39:56 +0200
From: Marco Elver <elver@...gle.com>
To: elver@...gle.com
Cc: akiyks@...il.com, stern@...land.harvard.edu, glider@...gle.com,
parri.andrea@...il.com, andreyknvl@...gle.com, luto@...nel.org,
ard.biesheuvel@...aro.org, arnd@...db.de, boqun.feng@...il.com,
bp@...en8.de, dja@...ens.net, dlustig@...dia.com,
dave.hansen@...ux.intel.com, dhowells@...hat.com,
dvyukov@...gle.com, hpa@...or.com, mingo@...hat.com,
j.alglave@....ac.uk, joel@...lfernandes.org, corbet@....net,
jpoimboe@...hat.com, luc.maranget@...ia.fr, mark.rutland@....com,
npiggin@...il.com, paulmck@...ux.ibm.com, peterz@...radead.org,
tglx@...utronix.de, will@...nel.org, kasan-dev@...glegroups.com,
linux-arch@...r.kernel.org, linux-doc@...r.kernel.org,
linux-efi@...r.kernel.org, linux-kbuild@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org, x86@...nel.org
Subject: [PATCH 5/8] seqlock: Require WRITE_ONCE surrounding raw_seqcount_barrier
This patch proposes to require marked atomic accesses surrounding
raw_write_seqcount_barrier. We reason that otherwise there is no way to
guarantee propagation nor atomicity of writes before/after the barrier
[1]. For example, consider the compiler tears stores either before or
after the barrier; in this case, readers may observe a partial value,
and because readers are unaware that writes are going on (writes are not
in a seq-writer critical section), will complete the seq-reader critical
section while having observed some partial state.
[1] https://lwn.net/Articles/793253/
This came up when designing and implementing KCSAN, because KCSAN would
flag these accesses as data-races. After careful analysis, our reasoning
as above led us to conclude that the best thing to do is to propose an
amendment to the raw_seqcount_barrier usage.
Signed-off-by: Marco Elver <elver@...gle.com>
---
include/linux/seqlock.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index 1e425831a7ed..5d50aad53b47 100644
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -265,6 +265,13 @@ static inline void raw_write_seqcount_end(seqcount_t *s)
* usual consistency guarantee. It is one wmb cheaper, because we can
* collapse the two back-to-back wmb()s.
*
+ * Note that, writes surrounding the barrier should be declared atomic (e.g.
+ * via WRITE_ONCE): a) to ensure the writes become visible to other threads
+ * atomically, avoiding compiler optimizations; b) to document which writes are
+ * meant to propagate to the reader critical section. This is necessary because
+ * neither writes before and after the barrier are enclosed in a seq-writer
+ * critical section that would ensure readers are aware of ongoing writes.
+ *
* seqcount_t seq;
* bool X = true, Y = false;
*
--
2.23.0.700.g56cf767bdb-goog
Powered by blists - more mailing lists