Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 28 Nov 2022 10:45:40 +0100
Mime-Version: 1.0
Message-ID: <20221128094541.2645890-1-glider@google.com>
Subject: [PATCH 1/2] lockdep: allow instrumenting lockdep.c with KMSAN
From:   Alexander Potapenko <glider@google.com>
To:     glider@google.com
Cc:     linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
        peterz@infradead.org, mingo@redhat.com, will@kernel.org,
        elver@google.com, dvyukov@google.com, linux-mm@kvack.org,
        kasan-dev@googlegroups.com, Eric Biggers <ebiggers@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Lockdep and KMSAN used to play badly together, causing deadlocks when
KMSAN instrumentation of lockdep.c called lockdep functions recursively.

Looks like this is no more the case, and a kernel can run (yet slower)
with both KMSAN and lockdep enabled.
This patch should fix false positives on wq_head->lock->dep_map, which
KMSAN used to consider uninitialized because of lockdep.c not being
instrumented.

Link: https://lore.kernel.org/lkml/Y3b9AAEKp2Vr3e6O@sol.localdomain/
Reported-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Alexander Potapenko <glider@google.com>
---
 kernel/locking/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/locking/Makefile b/kernel/locking/Makefile
index ea925731fa40f..0db4093d17b8a 100644
--- a/kernel/locking/Makefile
+++ b/kernel/locking/Makefile
@@ -7,7 +7,6 @@ obj-y += mutex.o semaphore.o rwsem.o percpu-rwsem.o
 
 # Avoid recursion lockdep -> sanitizer -> ... -> lockdep.
 KCSAN_SANITIZE_lockdep.o := n
-KMSAN_SANITIZE_lockdep.o := n
 
 ifdef CONFIG_FUNCTION_TRACER
 CFLAGS_REMOVE_lockdep.o = $(CC_FLAGS_FTRACE)
-- 
2.38.1.584.g0f3c55d4c2-goog