From patchwork Thu Nov 18 08:10:04 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marco Elver X-Patchwork-Id: 12626179 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EAB98C43217 for ; Thu, 18 Nov 2021 08:11:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7830961B97 for ; Thu, 18 Nov 2021 08:11:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7830961B97 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id E0E246B0072; Thu, 18 Nov 2021 03:11:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DBDC36B0073; Thu, 18 Nov 2021 03:11:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CAC826B0074; Thu, 18 Nov 2021 03:11:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0161.hostedemail.com [216.40.44.161]) by kanga.kvack.org (Postfix) with ESMTP id B7FF26B0072 for ; Thu, 18 Nov 2021 03:11:08 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 715E7184008B9 for ; Thu, 18 Nov 2021 08:10:58 +0000 (UTC) X-FDA: 78821330196.29.3DFBF5D Received: from mail-wm1-f73.google.com (mail-wm1-f73.google.com [209.85.128.73]) by imf12.hostedemail.com (Postfix) with ESMTP id 2230410003C0 for ; Thu, 18 Nov 2021 08:10:58 +0000 (UTC) Received: by mail-wm1-f73.google.com with SMTP id 201-20020a1c04d2000000b003335bf8075fso2272967wme.0 for ; Thu, 18 Nov 2021 00:10:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:message-id:mime-version:subject:from:to:cc; bh=Xzmo5mL9yKPgm1lZgxwsGIqYX+i9650OydzQnMolJjY=; b=qEJtN/DkSyckbRSxlIM9urYoLsb2hj7lFIxxPrdCEa/J11GugPm++lQKPAoPPA/En1 HAagnvpvld0c59y1nXQoSdU28kF6v7drYbyhjp6FCwRLAsX/zbPyFI5xXRjX8rc1oGu3 n5feY5KpUMjB4gzg7AMoJZWwyizpAXiugdaNx2kE2ILSDG1LgPsLdzEJCucQPCrvbhqd 8Hkype+TRhQp2L++fjjiYl8j4BG4Hz1E9HM5WKmImoj0fMbgcitWazJ9QMo6GxkbtIlw YB4XpISSa3H3WuSWwlvkFRqnezzu26Jka/PzoDc7lqgYBOcl/r+/Uc4wFXuLaCec3va2 H87g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=Xzmo5mL9yKPgm1lZgxwsGIqYX+i9650OydzQnMolJjY=; b=7T3WmXKho+QzOr8wGmUGuZTneOnYLGKfnOG6CSrW7himhrLwmbldiGojiONQHsV4TY jdkoLWEttylzVHcYxzPGnOTeQp+cItrelmA2BFlq+ltTuR9Xq9UAunQ4/B6pVkFCixro Q8J62FVUraNwSJRc26fcMVui7MwL1EB4W/Gs0cdz4FOy+5GJ8DSEnpL0Fe6369ItDosZ v5KpaBIXH68sSxuw2JV6NpKUJtATCB804bhWNbiTtyDefiXL8FDP9RaJVz5wYLV33Ww6 nZkLWoLewavWvwjq7vNJZR9AX25D9+MzuN7dE4fAy197hj4zNnLpIW2KREcCOSIh146i YImg== X-Gm-Message-State: AOAM53378V0kaQNR3FWm+YP8fRTP7zg1/1CqkHHuUmIROOer5QbJ5m5s gJc+rlCYoC/xrSJRNWUw/9MrZZAxkg== X-Google-Smtp-Source: ABdhPJzf0beCDskxs6TLI9QKNEqbgr6M0bT4DWDT314iI+YiTOIk1FtVgaYUzMPaVpD7QqDDgrzhRBUpaw== X-Received: from elver.muc.corp.google.com ([2a00:79e0:15:13:7155:1b7:fca5:3926]) (user=elver job=sendgmr) by 2002:a5d:4e52:: with SMTP id r18mr26521150wrt.224.1637223056499; Thu, 18 Nov 2021 00:10:56 -0800 (PST) Date: Thu, 18 Nov 2021 09:10:04 +0100 Message-Id: <20211118081027.3175699-1-elver@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.34.0.rc2.393.gf8c9666880-goog Subject: [PATCH v2 00/23] kcsan: Support detecting a subset of missing memory barriers From: Marco Elver To: elver@google.com, "Paul E. McKenney" Cc: Alexander Potapenko , Boqun Feng , Borislav Petkov , Dmitry Vyukov , Ingo Molnar , Josh Poimboeuf , Mark Rutland , Peter Zijlstra , Thomas Gleixner , Waiman Long , Will Deacon , kasan-dev@googlegroups.com, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 2230410003C0 X-Stat-Signature: s9hafz93qt53ozt6pxcf7qex56c3fqw7 Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="qEJtN/Dk"; spf=pass (imf12.hostedemail.com: domain of 3kAqWYQUKCBEv2Cv8x55x2v.t532z4BE-331Crt1.58x@flex--elver.bounces.google.com designates 209.85.128.73 as permitted sender) smtp.mailfrom=3kAqWYQUKCBEv2Cv8x55x2v.t532z4BE-331Crt1.58x@flex--elver.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1637223058-777054 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Detection of some missing memory barriers has been on the KCSAN feature wishlist for some time: this series adds support for modeling a subset of weak memory as defined by the LKMM, which enables detection of a subset of data races due to missing memory barriers. KCSAN's approach to detecting missing memory barriers is based on modeling access reordering. Each memory access for which a watchpoint is set up, is also selected for simulated reordering within the scope of its function (at most 1 in-flight access). We are limited to modeling the effects of "buffering" (delaying the access), since the runtime cannot "prefetch" accesses. Once an access has been selected for reordering, it is checked along every other access until the end of the function scope. If an appropriate memory barrier is encountered, the access will no longer be considered for reordering. When the result of a memory operation should be ordered by a barrier, KCSAN can then detect data races where the conflict only occurs as a result of a missing barrier due to reordering accesses. Some more details and an example are captured in the updated . Some light fuzzing with the feature also resulted in a discussion [1] around an issue which appears to be allowed, but unlikely in practice. [1] https://lkml.kernel.org/r/YRo58c+JGOvec7tc@elver.google.com The first half of the series are core KCSAN changes, documentation updates, and test changes. The second half adds instrumentation to barriers, atomics, bitops, along with enabling barrier instrumentation for some currently uninstrumented subsystems. The last two patches are objtool changes to add the usual entries to the uaccess whitelist, but also instruct objtool to remove memory barrier instrumentation from noinstr code (on x86). --- v2: * Rewrite objtool patch after rebase to v5.16-rc1. * Note the reason in documentation that address or control dependencies do not require special handling. * Rename kcsan_atomic_release() to kcsan_atomic_builtin_memorder() to avoid confusion. * Define kcsan_noinstr as noinline if we rely on objtool nop'ing out calls, to avoid things like LTO inlining it. v1: https://lore.kernel.org/all/20211005105905.1994700-1-elver@google.com/ Marco Elver (23): kcsan: Refactor reading of instrumented memory kcsan: Remove redundant zero-initialization of globals kcsan: Avoid checking scoped accesses from nested contexts kcsan: Add core support for a subset of weak memory modeling kcsan: Add core memory barrier instrumentation functions kcsan, kbuild: Add option for barrier instrumentation only kcsan: Call scoped accesses reordered in reports kcsan: Show location access was reordered to kcsan: Document modeling of weak memory kcsan: test: Match reordered or normal accesses kcsan: test: Add test cases for memory barrier instrumentation kcsan: Ignore GCC 11+ warnings about TSan runtime support kcsan: selftest: Add test case to check memory barrier instrumentation locking/barriers, kcsan: Add instrumentation for barriers locking/barriers, kcsan: Support generic instrumentation locking/atomics, kcsan: Add instrumentation for barriers asm-generic/bitops, kcsan: Add instrumentation for barriers x86/barriers, kcsan: Use generic instrumentation for non-smp barriers x86/qspinlock, kcsan: Instrument barrier of pv_queued_spin_unlock() mm, kcsan: Enable barrier instrumentation sched, kcsan: Enable memory barrier instrumentation objtool, kcsan: Add memory barrier instrumentation to whitelist objtool, kcsan: Remove memory barrier instrumentation from noinstr Documentation/dev-tools/kcsan.rst | 76 +++- arch/x86/include/asm/barrier.h | 10 +- arch/x86/include/asm/qspinlock.h | 1 + include/asm-generic/barrier.h | 54 ++- .../asm-generic/bitops/instrumented-atomic.h | 3 + .../asm-generic/bitops/instrumented-lock.h | 3 + include/linux/atomic/atomic-instrumented.h | 135 +++++- include/linux/kcsan-checks.h | 51 ++- include/linux/kcsan.h | 11 +- include/linux/sched.h | 3 + include/linux/spinlock.h | 2 +- init/init_task.c | 9 +- kernel/kcsan/Makefile | 2 + kernel/kcsan/core.c | 326 +++++++++++--- kernel/kcsan/kcsan_test.c | 416 ++++++++++++++++-- kernel/kcsan/report.c | 51 ++- kernel/kcsan/selftest.c | 141 ++++++ kernel/sched/Makefile | 7 +- lib/Kconfig.kcsan | 16 + mm/Makefile | 2 + scripts/Makefile.kcsan | 15 +- scripts/Makefile.lib | 5 + scripts/atomic/gen-atomic-instrumented.sh | 41 +- tools/objtool/check.c | 41 +- tools/objtool/include/objtool/elf.h | 2 +- 25 files changed, 1248 insertions(+), 175 deletions(-)