From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6BCE0C433F5 for ; Tue, 14 Dec 2021 22:05:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238040AbhLNWFM (ORCPT ); Tue, 14 Dec 2021 17:05:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53644 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237856AbhLNWEp (ORCPT ); Tue, 14 Dec 2021 17:04:45 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0F9E4C06173E for ; Tue, 14 Dec 2021 14:04:45 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8070A6176F for ; Tue, 14 Dec 2021 22:04:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2C284C34636; Tue, 14 Dec 2021 22:04:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1639519482; bh=x5OIp1ip+icHRnyBqGFrJUAWB2L7ly/SEk6OQoAqt1w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YgGvLEFM/ReiO4NzC7S1Vwwx/bAAgdGbN5Ufp8F5t4xDrksnzSioxQ4ZJ+BT/I8Nz nyV5oN7wdf96ZC6Ulqq1rcZqRE2KMYelxEnv3smLX0olsACmTxmfgGWhmh29+LTfrC kxdoXoXXmkf6k+gPCxgPIhsg7ueDDoVWxXbEyhoGS/OENRjxWXxzJl0uBNyXkYscC6 1sETaMpWO5flc3NQYQVTDHKn+kuXc5kAgd4L4/CCBeu8t9VHkZ3bGKgAwAg84znJvA BYMejb2V/7Ieye2CE7h7SnrdRvtbhddrxxstl/ynVmZ70AP8RLQIwFMkTqmXRqUr0t zZFQroYRs/6oA== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 80C0A5C1E84; Tue, 14 Dec 2021 14:04:41 -0800 (PST) From: "Paul E. McKenney" To: linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, kernel-team@fb.com, mingo@kernel.org Cc: elver@google.com, andreyknvl@google.com, glider@google.com, dvyukov@google.com, cai@lca.pw, boqun.feng@gmail.com, "Paul E . McKenney" Subject: [PATCH kcsan 20/29] mm, kcsan: Enable barrier instrumentation Date: Tue, 14 Dec 2021 14:04:30 -0800 Message-Id: <20211214220439.2236564-20-paulmck@kernel.org> X-Mailer: git-send-email 2.31.1.189.g2e36527f23 In-Reply-To: <20211214220356.GA2236323@paulmck-ThinkPad-P17-Gen-1> References: <20211214220356.GA2236323@paulmck-ThinkPad-P17-Gen-1> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Marco Elver 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 <-+ | *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 Signed-off-by: Paul E. McKenney --- mm/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/Makefile b/mm/Makefile index d6c0042e3aa0d..7919cd7f13f2a 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.31.1.189.g2e36527f23