From patchwork Tue Nov 30 11:44:33 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marco Elver X-Patchwork-Id: 12647109 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3476BC433F5 for ; Tue, 30 Nov 2021 11:57:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4E9F06B009A; Tue, 30 Nov 2021 06:46:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 49AB26B009B; Tue, 30 Nov 2021 06:46:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 362636B009C; Tue, 30 Nov 2021 06:46:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0152.hostedemail.com [216.40.44.152]) by kanga.kvack.org (Postfix) with ESMTP id 27BF06B009A for ; Tue, 30 Nov 2021 06:46:16 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E4924183F96A6 for ; Tue, 30 Nov 2021 11:46:05 +0000 (UTC) X-FDA: 78865417848.27.06B6752 Received: from mail-wm1-f74.google.com (mail-wm1-f74.google.com [209.85.128.74]) by imf16.hostedemail.com (Postfix) with ESMTP id AF57DF0000A0 for ; Tue, 30 Nov 2021 11:45:59 +0000 (UTC) Received: by mail-wm1-f74.google.com with SMTP id i131-20020a1c3b89000000b00337f92384e0so13610018wma.5 for ; Tue, 30 Nov 2021 03:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=ykQMG7f7HitTY02bjgroWOqQwac8nTYOVAZLqTXm/og=; b=qfKYXOVzY2MTzD2zIwUpOpLCYIanN5AfAyzY4pD6y/00NCNsZhMgCXyQuHgqHRjMQP 2Q4GpB2kKiA9NG+mxwbdwhx/T6uztpsr0cPDZKwOOV4NBkpo8wKmqUMwj6QIZ50+WTGC rj+XujQ6x15SViviNrLc8ryKZTpDmfQ59NmqPKusALt7vIXW09vUdxRhx/IHgX0O1Fi0 peXM6+tWJqwR46RttMZspmzxuv6mgkZjTPQRNEx0+Evh/SfhzkOebPUPea948l/PAD60 8d8gkegUNMa+NHH1FPVvEqF67z8VdDW4GAXutQLRg58SDKDe/Mh9BClDvEsEpsff6SiM sbTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=ykQMG7f7HitTY02bjgroWOqQwac8nTYOVAZLqTXm/og=; b=7JR9KgpzaOXfwJQOAMP6o59nHCOWBcuA4LPsAnxVjnlKcORPhpNxwGxlgyaPYW5j63 1voW5xcuXWTkXNsMwDLIDPJl8tPyc/merqckP/TKdPqD75I7ejwxMrpbNUY7ElB50LRC Pnp/j7kkI4mvGa6L9eA3/6IQIid0LWQrM01wZobSXaV5rD7+GjCStPGp7TdeUQMTVH37 VrIV/UlgSQz7kjRQqXiXwYwo0UPYM+H1YFFuk0XL1pEDp8ABf1+9HXK4GqH8kKuWnNDG 31svqUH4b2wn1OlBKx6qint6sHlv4yQBtVGNrmox71MHCKxz3sXw7peS4oLAMmSj9k7I etDg== X-Gm-Message-State: AOAM533wAUjYE4xDcrHdwRybtVHN/lfE2ZiG1/t/dRUkntpoaAXKJZg8 GHLIfi2EsUKZixNfH+TafOGujSWv4Q== X-Google-Smtp-Source: ABdhPJw6whH8Hls3EC+BgAy91BvIDfMtsebOG9cJCkHwE7EfRIVxArLwzYtCPhRhlBjkro/EFip+BpGtoQ== X-Received: from elver.muc.corp.google.com ([2a00:79e0:15:13:86b7:11e9:7797:99f0]) (user=elver job=sendgmr) by 2002:a05:600c:4f0b:: with SMTP id l11mr626212wmq.0.1638272763966; Tue, 30 Nov 2021 03:46:03 -0800 (PST) Date: Tue, 30 Nov 2021 12:44:33 +0100 In-Reply-To: <20211130114433.2580590-1-elver@google.com> Message-Id: <20211130114433.2580590-26-elver@google.com> Mime-Version: 1.0 References: <20211130114433.2580590-1-elver@google.com> X-Mailer: git-send-email 2.34.0.rc2.393.gf8c9666880-goog Subject: [PATCH v3 25/25] kcsan: Support WEAK_MEMORY with Clang where no objtool support exists From: Marco Elver To: elver@google.com, "Paul E. McKenney" Cc: Alexander Potapenko , Boqun Feng , Borislav Petkov , Dmitry Vyukov , Ingo Molnar , 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, llvm@lists.linux.dev, x86@kernel.org X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: AF57DF0000A0 X-Stat-Signature: wbxbk1g3i5rt8cscbkyw9jcdcg16nuwt Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=qfKYXOVz; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of 3-w6mYQUKCMQov5o1qyyqvo.mywvsx47-wwu5kmu.y1q@flex--elver.bounces.google.com designates 209.85.128.74 as permitted sender) smtp.mailfrom=3-w6mYQUKCMQov5o1qyyqvo.mywvsx47-wwu5kmu.y1q@flex--elver.bounces.google.com X-HE-Tag: 1638272759-52226 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: Clang and GCC behave a little differently when it comes to the __no_sanitize_thread attribute, which has valid reasons, and depending on context either one could be right. Traditionally, user space ThreadSanitizer [1] still expects instrumented builtin atomics (to avoid false positives) and __tsan_func_{entry,exit} (to generate meaningful stack traces), even if the function has the attribute no_sanitize("thread"). [1] https://clang.llvm.org/docs/ThreadSanitizer.html#attribute-no-sanitize-thread GCC doesn't follow the same policy (for better or worse), and removes all kinds of instrumentation if no_sanitize is added. Arguably, since this may be a problem for user space ThreadSanitizer, we expect this may change in future. Since KCSAN != ThreadSanitizer, the likelihood of false positives even without barrier instrumentation everywhere, is much lower by design. At least for Clang, however, to fully remove all sanitizer instrumentation, we must add the disable_sanitizer_instrumentation attribute, which is available since Clang 14.0. Signed-off-by: Marco Elver --- v3: * New patch. --- include/linux/compiler_types.h | 13 ++++++++++++- lib/Kconfig.kcsan | 2 +- 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h index 1d32f4c03c9e..3c1795fdb568 100644 --- a/include/linux/compiler_types.h +++ b/include/linux/compiler_types.h @@ -198,9 +198,20 @@ struct ftrace_likely_data { # define __no_kasan_or_inline __always_inline #endif -#define __no_kcsan __no_sanitize_thread #ifdef __SANITIZE_THREAD__ +/* + * Clang still emits instrumentation for __tsan_func_{entry,exit}() and builtin + * atomics even with __no_sanitize_thread (to avoid false positives in userspace + * ThreadSanitizer). The kernel's requirements are stricter and we really do not + * want any instrumentation with __no_kcsan. + * + * Therefore we add __disable_sanitizer_instrumentation where available to + * disable all instrumentation. See Kconfig.kcsan where this is mandatory. + */ +# define __no_kcsan __no_sanitize_thread __disable_sanitizer_instrumentation # define __no_sanitize_or_inline __no_kcsan notrace __maybe_unused +#else +# define __no_kcsan #endif #ifndef __no_sanitize_or_inline diff --git a/lib/Kconfig.kcsan b/lib/Kconfig.kcsan index e4394ea8068b..63b70b8c5551 100644 --- a/lib/Kconfig.kcsan +++ b/lib/Kconfig.kcsan @@ -198,7 +198,7 @@ config KCSAN_WEAK_MEMORY # We can either let objtool nop __tsan_func_{entry,exit}() and builtin # atomics instrumentation in .noinstr.text, or use a compiler that can # implement __no_kcsan to really remove all instrumentation. - depends on STACK_VALIDATION || CC_IS_GCC + depends on STACK_VALIDATION || CC_IS_GCC || CLANG_VERSION >= 140000 help Enable support for modeling a subset of weak memory, which allows detecting a subset of data races due to missing memory barriers.