linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: elver@google.com
Cc: akiyks@gmail.com, stern@rowland.harvard.edu, glider@google.com,
	 parri.andrea@gmail.com, andreyknvl@google.com, luto@kernel.org,
	 ard.biesheuvel@linaro.org, arnd@arndb.de, boqun.feng@gmail.com,
	bp@alien8.de,  dja@axtens.net, dlustig@nvidia.com,
	dave.hansen@linux.intel.com,  dhowells@redhat.com,
	dvyukov@google.com, hpa@zytor.com, mingo@redhat.com,
	 j.alglave@ucl.ac.uk, joel@joelfernandes.org, corbet@lwn.net,
	 jpoimboe@redhat.com, luc.maranget@inria.fr,
	mark.rutland@arm.com,  npiggin@gmail.com, paulmck@kernel.org,
	peterz@infradead.org,  tglx@linutronix.de, will@kernel.org,
	kasan-dev@googlegroups.com,  linux-arch@vger.kernel.org,
	linux-doc@vger.kernel.org,  linux-efi@vger.kernel.org,
	linux-kbuild@vger.kernel.org,  linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, x86@kernel.org
Subject: [PATCH v3 6/9] seqlock: Require WRITE_ONCE surrounding raw_seqcount_barrier
Date: Mon,  4 Nov 2019 15:27:42 +0100	[thread overview]
Message-ID: <20191104142745.14722-7-elver@google.com> (raw)
In-Reply-To: <20191104142745.14722-1-elver@google.com>

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@google.com>
---
v3:
* Add missing comment that was in preceding seqlock patch.
---
 include/linux/seqlock.h | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index 61232bc223fd..f52c91be8939 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;
  *
@@ -284,11 +291,11 @@ static inline void raw_write_seqcount_end(seqcount_t *s)
  *
  *      void write(void)
  *      {
- *              Y = true;
+ *              WRITE_ONCE(Y, true);
  *
  *              raw_write_seqcount_barrier(seq);
  *
- *              X = false;
+ *              WRITE_ONCE(X, false);
  *      }
  */
 static inline void raw_write_seqcount_barrier(seqcount_t *s)
-- 
2.24.0.rc1.363.gb1bccd3e3d-goog



  parent reply	other threads:[~2019-11-04 14:29 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-04 14:27 [PATCH v3 0/9] Add Kernel Concurrency Sanitizer (KCSAN) Marco Elver
2019-11-04 14:27 ` [PATCH v3 1/9] kcsan: Add Kernel Concurrency Sanitizer infrastructure Marco Elver
2019-11-06  9:38   ` Dmitry Vyukov
2019-11-06 10:03     ` Marco Elver
2019-11-06 19:11     ` Marco Elver
2019-11-06 19:59   ` kbuild test robot
2019-11-06 20:34   ` kbuild test robot
2019-11-07 18:43     ` Marco Elver
2019-11-07 21:08   ` Bhupesh Sharma
2019-11-08 14:23     ` Marco Elver
2019-11-04 14:27 ` [PATCH v3 2/9] kcsan: Add Documentation entry in dev-tools Marco Elver
2019-11-04 14:27 ` [PATCH v3 3/9] objtool, kcsan: Add KCSAN runtime functions to whitelist Marco Elver
2019-11-04 14:27 ` [PATCH v3 4/9] build, kcsan: Add KCSAN build exceptions Marco Elver
2019-11-04 14:27 ` [PATCH v3 5/9] seqlock, kcsan: Add annotations for KCSAN Marco Elver
2019-11-05 11:35   ` kbuild test robot
2019-11-05 15:22     ` Marco Elver
2019-11-04 14:27 ` Marco Elver [this message]
2019-11-04 14:27 ` [PATCH v3 7/9] asm-generic, kcsan: Add KCSAN instrumentation for bitops Marco Elver
2019-11-04 14:27 ` [PATCH v3 8/9] locking/atomics, kcsan: Add KCSAN instrumentation Marco Elver
2019-11-04 14:27 ` [PATCH v3 9/9] x86, kcsan: Enable KCSAN for x86 Marco Elver
2019-11-04 16:47 ` [PATCH v3 0/9] Add Kernel Concurrency Sanitizer (KCSAN) Paul E. McKenney
2019-11-04 18:41   ` Marco Elver
2019-11-04 19:46     ` Paul E. McKenney
2019-11-05 11:10       ` Marco Elver
2019-11-05 14:20         ` Paul E. McKenney
2019-11-05 15:25           ` Marco Elver
2019-11-14 18:05             ` Marco Elver
2019-11-14 19:48               ` Paul E. McKenney

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=20191104142745.14722-7-elver@google.com \
    --to=elver@google.com \
    --cc=akiyks@gmail.com \
    --cc=andreyknvl@google.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=boqun.feng@gmail.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=dhowells@redhat.com \
    --cc=dja@axtens.net \
    --cc=dlustig@nvidia.com \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=hpa@zytor.com \
    --cc=j.alglave@ucl.ac.uk \
    --cc=joel@joelfernandes.org \
    --cc=jpoimboe@redhat.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luc.maranget@inria.fr \
    --cc=luto@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=npiggin@gmail.com \
    --cc=parri.andrea@gmail.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=stern@rowland.harvard.edu \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).