[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20211130114433.2580590-21-elver@google.com>
Date: Tue, 30 Nov 2021 12:44:28 +0100
From: Marco Elver <elver@...gle.com>
To: elver@...gle.com, "Paul E. McKenney" <paulmck@...nel.org>
Cc: Alexander Potapenko <glider@...gle.com>,
Boqun Feng <boqun.feng@...il.com>,
Borislav Petkov <bp@...en8.de>,
Dmitry Vyukov <dvyukov@...gle.com>,
Ingo Molnar <mingo@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Waiman Long <longman@...hat.com>,
Will Deacon <will@...nel.org>, kasan-dev@...glegroups.com,
linux-arch@...r.kernel.org, linux-doc@...r.kernel.org,
linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, llvm@...ts.linux.dev, x86@...nel.org
Subject: [PATCH v3 20/25] mm, kcsan: Enable barrier instrumentation
Some memory management calls imply memory barriers that are required to
avoid false positives. For example, without the correct instrumentation,
we could observe data races of the following variant:
T0 | T1
------------------------+------------------------
|
*a = 42; ---+ |
kfree(a); | |
| | b = kmalloc(..); // b == a
<reordered> <-+ | *b = 42; // not a data race!
|
Therefore, instrument memory barriers in all allocator code currently
not being instrumented in a default build.
Signed-off-by: Marco Elver <elver@...gle.com>
---
mm/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/Makefile b/mm/Makefile
index d6c0042e3aa0..7919cd7f13f2 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -15,6 +15,8 @@ KCSAN_SANITIZE_slab_common.o := n
KCSAN_SANITIZE_slab.o := n
KCSAN_SANITIZE_slub.o := n
KCSAN_SANITIZE_page_alloc.o := n
+# But enable explicit instrumentation for memory barriers.
+KCSAN_INSTRUMENT_BARRIERS := y
# These files are disabled because they produce non-interesting and/or
# flaky coverage that is not a function of syscall inputs. E.g. slab is out of
--
2.34.0.rc2.393.gf8c9666880-goog
Powered by blists - more mailing lists