Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp2742784ybh; Mon, 9 Mar 2020 12:05:09 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvLg2xsnGuVrAJ+VT3n8AewYxnFIh2z9SCXaPTcLhCdZHvmDuEq3vItzP2FLaz7T8cbzh1e X-Received: by 2002:aca:aa8b:: with SMTP id t133mr4942oie.95.1583780709699; Mon, 09 Mar 2020 12:05:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583780709; cv=none; d=google.com; s=arc-20160816; b=YV5k8ovDrE6AQv6UA4uoYX/cYkLXDEen9yCYbXWFuKdFKYbh1eR4eM52Zmq1IUjCjq AjPz7GXRimcz7h+q8r3CWf4M5Y2ZBUCpWhoebcf6Q51lO/u00ih4Nz8A4wGg5omDWjz/ AgylPdnpmgZ+4ga6qPbB1ClgA5bUguGx1/p23gEbB4aiSubdH1TQ/17bgrYJFoCbEjtO SZDdz/M0OlSS01p74oMUaey8LoKXatPMXzgQKJfE+CItku/vzWt8x86QNYH3+T5DfzVR l4FIIBvw9NzU29TWoc7IFfrMK6Q+B6J5RoPXtwIU+tkFiJw1VOY6aMED+tbzwTDkRdok kH7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature; bh=iBolY0lxP7pU+p8c4+lbD7T5UBtwQdW+/cUetIYHyJA=; b=tJfMsy3jRAcYre8hw48N8Lsg9lGfXqDA8Z4Mcof71c18IbDV7aoWnGHaB0HAlnILkD SfChGtX0QuI+2M6Mh/Yow4e5AKzMyNKxNqZg9RdmxKB9dYIQhD6Ydyxdg22VnO1Fj218 piiZltiT1xZzt4oDiY55puTeezGU6GV5hnHiWhAL5k4kW6v3gAjN1CFeWx2jWtqsmwJR LhgTiUj16faHoEkIOW99MouQhvV7MYpzhAIuMgCQ6BYGGhkcbIlzqnMMPtDX0VvNmXjl EAFQlxLEyvBq0b2fQ+rvj0P7GsO1TPrA0SELwJUnnwJ+jEUZNKqmYXSuZMA4N9UXCAth ouCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=LLCKQzKR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k15si6507880otb.208.2020.03.09.12.04.57; Mon, 09 Mar 2020 12:05:09 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=LLCKQzKR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727619AbgCITE1 (ORCPT + 99 others); Mon, 9 Mar 2020 15:04:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:47610 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727579AbgCITEZ (ORCPT ); Mon, 9 Mar 2020 15:04:25 -0400 Received: from paulmck-ThinkPad-P72.home (50-39-105-78.bvtn.or.frontiernet.net [50.39.105.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1A46F2465A; Mon, 9 Mar 2020 19:04:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583780665; bh=nvxvgWdtEgnDRqamc2GBWCsWAoOX94Fj8G+9vEM+csI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LLCKQzKRVJcFGcG2+Cl2hY/Ds3fWou+kMjKhrUohcvjKDlTjTBrJbD9UkbnYsLqbb HRG/MRLvhE9k0yKiz5ntxrnmi1Kalh0ACqKg/GNHX1mL2x3z2vGGpsMpas+7QANJkT fc58l1eCTQmkC9OXQHFog4dXzz6JXlaWYiTtqzJ4= From: paulmck@kernel.org 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 12/32] kcsan: Add option to assume plain aligned writes up to word size are atomic Date: Mon, 9 Mar 2020 12:04:00 -0700 Message-Id: <20200309190420.6100-12-paulmck@kernel.org> X-Mailer: git-send-email 2.9.5 In-Reply-To: <20200309190359.GA5822@paulmck-ThinkPad-P72> References: <20200309190359.GA5822@paulmck-ThinkPad-P72> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Marco Elver This adds option KCSAN_ASSUME_PLAIN_WRITES_ATOMIC. If enabled, plain aligned writes up to word size are assumed to be atomic, and also not subject to other unsafe compiler optimizations resulting in data races. This option has been enabled by default to reflect current kernel-wide preferences. Signed-off-by: Marco Elver Signed-off-by: Paul E. McKenney --- kernel/kcsan/core.c | 22 +++++++++++++++++----- lib/Kconfig.kcsan | 27 ++++++++++++++++++++------- 2 files changed, 37 insertions(+), 12 deletions(-) diff --git a/kernel/kcsan/core.c b/kernel/kcsan/core.c index 64b30f7..e3c7d8f 100644 --- a/kernel/kcsan/core.c +++ b/kernel/kcsan/core.c @@ -5,6 +5,7 @@ #include #include #include +#include #include #include #include @@ -169,10 +170,20 @@ static __always_inline struct kcsan_ctx *get_ctx(void) return in_task() ? ¤t->kcsan_ctx : raw_cpu_ptr(&kcsan_cpu_ctx); } -static __always_inline bool is_atomic(const volatile void *ptr) +static __always_inline bool +is_atomic(const volatile void *ptr, size_t size, int type) { - struct kcsan_ctx *ctx = get_ctx(); + struct kcsan_ctx *ctx; + + if ((type & KCSAN_ACCESS_ATOMIC) != 0) + return true; + if (IS_ENABLED(CONFIG_KCSAN_ASSUME_PLAIN_WRITES_ATOMIC) && + (type & KCSAN_ACCESS_WRITE) != 0 && size <= sizeof(long) && + IS_ALIGNED((unsigned long)ptr, size)) + return true; /* Assume aligned writes up to word size are atomic. */ + + ctx = get_ctx(); if (unlikely(ctx->atomic_next > 0)) { /* * Because we do not have separate contexts for nested @@ -193,7 +204,8 @@ static __always_inline bool is_atomic(const volatile void *ptr) return kcsan_is_atomic(ptr); } -static __always_inline bool should_watch(const volatile void *ptr, int type) +static __always_inline bool +should_watch(const volatile void *ptr, size_t size, int type) { /* * Never set up watchpoints when memory operations are atomic. @@ -202,7 +214,7 @@ static __always_inline bool should_watch(const volatile void *ptr, int type) * should not count towards skipped instructions, and (2) to actually * decrement kcsan_atomic_next for consecutive instruction stream. */ - if ((type & KCSAN_ACCESS_ATOMIC) != 0 || is_atomic(ptr)) + if (is_atomic(ptr, size, type)) return false; if (this_cpu_dec_return(kcsan_skip) >= 0) @@ -460,7 +472,7 @@ static __always_inline void check_access(const volatile void *ptr, size_t size, if (unlikely(watchpoint != NULL)) kcsan_found_watchpoint(ptr, size, type, watchpoint, encoded_watchpoint); - else if (unlikely(should_watch(ptr, type))) + else if (unlikely(should_watch(ptr, size, type))) kcsan_setup_watchpoint(ptr, size, type); } diff --git a/lib/Kconfig.kcsan b/lib/Kconfig.kcsan index 3552990..6612685 100644 --- a/lib/Kconfig.kcsan +++ b/lib/Kconfig.kcsan @@ -91,13 +91,13 @@ config KCSAN_REPORT_ONCE_IN_MS limiting reporting to avoid flooding the console with reports. Setting this to 0 disables rate limiting. -# Note that, while some of the below options could be turned into boot -# parameters, to optimize for the common use-case, we avoid this because: (a) -# it would impact performance (and we want to avoid static branch for all -# {READ,WRITE}_ONCE, atomic_*, bitops, etc.), and (b) complicate the design -# without real benefit. The main purpose of the below options is for use in -# fuzzer configs to control reported data races, and they are not expected -# to be switched frequently by a user. +# The main purpose of the below options is to control reported data races (e.g. +# in fuzzer configs), and are not expected to be switched frequently by other +# users. We could turn some of them into boot parameters, but given they should +# not be switched normally, let's keep them here to simplify configuration. +# +# The defaults below are chosen to be very conservative, and may miss certain +# bugs. config KCSAN_REPORT_RACE_UNKNOWN_ORIGIN bool "Report races of unknown origin" @@ -116,6 +116,19 @@ config KCSAN_REPORT_VALUE_CHANGE_ONLY the data value of the memory location was observed to remain unchanged, do not report the data race. +config KCSAN_ASSUME_PLAIN_WRITES_ATOMIC + bool "Assume that plain aligned writes up to word size are atomic" + default y + help + Assume that plain aligned writes up to word size are atomic by + default, and also not subject to other unsafe compiler optimizations + resulting in data races. This will cause KCSAN to not report data + races due to conflicts where the only plain accesses are aligned + writes up to word size: conflicts between marked reads and plain + aligned writes up to word size will not be reported as data races; + notice that data races between two conflicting plain aligned writes + will also not be reported. + config KCSAN_IGNORE_ATOMICS bool "Do not instrument marked atomic accesses" help -- 2.9.5