Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5198115ybl; Tue, 4 Feb 2020 09:25:19 -0800 (PST) X-Google-Smtp-Source: APXvYqyozeIJbncbBLa33K1ki3pKNDIr2twuvK700qfRjnABjOjpyzhJezh7VCbDSpuxOWGQVlMo X-Received: by 2002:a05:6830:158:: with SMTP id j24mr23571493otp.316.1580837118949; Tue, 04 Feb 2020 09:25:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580837118; cv=none; d=google.com; s=arc-20160816; b=doGvP5SrpsyOCRnP+R/spEALnCyAIcI5o9zo5LE0bGY3z7b8l7U/FWHtJGatkDBvhF xhc3mBpKCtJsHcgDK8o2o1W2OBkoWxDoU5szPTtip9brLYqjO3OrY7St49AM5xp0Eck6 NYHj6LmcloF/8bE0Rh1DoMw6h5/Y74kWAc/0dgk7LPRVnNO+c+keMXqC47o28gbigG+o T9ECyMQiUGYsKDNZep8N7LilqEhDQRb7CrhvkRwGFxGvohz3Ys8hamXGTOTV+dbkWHIV BzQkOPbrnjg+uBLCvRhCIV05BMMfpGmtTQ1l+mpp62jccL79w4lKHdkqLhaSvPduViov 9lKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=WdU/+EXQPN08tVx0Omqu46OD1KCs9yfQsxA+mu440FM=; b=ApO8klSXXV74bNBiLNGKyed+bHEy3WzXLQ0A6O1SuBquLZW4333XCf2Eppjxt4WOpG Ykizs5FJE815sPWkrJXdV98bK3SgAapcCugkulTukMJh6dkM0UDIHY0A+L06Y0wppyzk S0a5LNU3LS8+vhzfBrIisCw7TgVS4XfFHRSRKE7bBd0yGyM2/ejm7R9unoI5qkqDFrcG DVRKUtu4RONNYrywT9j1m3D9vn24P0tOYN6p6n19cV84fRlVQctz5XaTsePBKDwcfvjb eIOzJnF7hG7l60WxIs4COWA0vHBubzYnsE9KbkWDhPVmaX0iXKZvTgE9FyX6LtzWiFfw cPdQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=iPVZGvXG; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f3si11005806oia.264.2020.02.04.09.25.06; Tue, 04 Feb 2020 09:25:18 -0800 (PST) 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=@google.com header.s=20161025 header.b=iPVZGvXG; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727466AbgBDRW5 (ORCPT + 99 others); Tue, 4 Feb 2020 12:22:57 -0500 Received: from mail-oi1-f196.google.com ([209.85.167.196]:46031 "EHLO mail-oi1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727308AbgBDRW5 (ORCPT ); Tue, 4 Feb 2020 12:22:57 -0500 Received: by mail-oi1-f196.google.com with SMTP id v19so19199622oic.12 for ; Tue, 04 Feb 2020 09:22:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WdU/+EXQPN08tVx0Omqu46OD1KCs9yfQsxA+mu440FM=; b=iPVZGvXGfBh1inJbO0YdK20ZBCVXEMHeler4kSYegphW0CJQi9jbvx1jt3ZM6SZeKc gaveKKl/tureoe6x+M6AiRoAZozmqns7F4qDGWiMpz6c3pXH2zVUMuC29D0yiU25WZDl eu1YYnT3M3H4Z6xJjLcMN4aYPsG67nl3fmdRSqb7uE9sLm73mvgd4iBkuYklwZsgmrYj 74jpk8aPh0d2l5aaWMI+ZxUtdyfA2wqx6FHI/7sD/E9OXeZosZGnca0wL+Vceq8jjACH jtiFp9tgFv0mJOEcTZSpMDoRInQTe6WOjc4kszR6AMDICueVBnEFu6ZidlwOUir+jUNZ 7m+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WdU/+EXQPN08tVx0Omqu46OD1KCs9yfQsxA+mu440FM=; b=eChj34sNakg/CwHkrFQ0pe2nBeyvzFdlwKP5OrAK4TXveegEKIDfDEdkbALesBWXh3 OHUfLb9ivt2wa6XNWuX5Hao80BUQv9+ZelSgcO0NP5EXi483KiwFby54llGsaBbWyOFL kKO1YtxlPXWEUYznaSCJCZqqL6qua0K6O7umO9KJVSwS9VX3V8ZE6ByOHbn84vp5S4SS klbp4xn67oo3nCoO5MKOyIzk0a1gmaAq5yg1Woa7N26tsn8q3aHi41fFtWDWSTQwlVq/ gStyz1gYs3lsqBAaVNVh14uuI9kH3eSvNJ4CfsoqxDU97cUUtYZgeaz9sUN82AclL2OS FJVg== X-Gm-Message-State: APjAAAWu2CKSTKVmxftRDvz+Jq6xw9MHqu0sBsCZYlYJHEno8gkzopgi LV7RJ22RoE3EmhgxE4j8WHKRY/3WYA/hoF1F3q2bLg== X-Received: by 2002:aca:2112:: with SMTP id 18mr47816oiz.155.1580836976510; Tue, 04 Feb 2020 09:22:56 -0800 (PST) MIME-Version: 1.0 References: <20200204140353.177797-1-elver@google.com> <20200204154015.GQ2935@paulmck-ThinkPad-P72> In-Reply-To: <20200204154015.GQ2935@paulmck-ThinkPad-P72> From: Marco Elver Date: Tue, 4 Feb 2020 18:22:45 +0100 Message-ID: Subject: Re: [PATCH 1/3] kcsan: Add option to assume plain writes up to word size are atomic To: "Paul E. McKenney" Cc: Andrey Konovalov , Alexander Potapenko , Dmitry Vyukov , kasan-dev , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 4 Feb 2020 at 16:40, Paul E. McKenney wrote: > > On Tue, Feb 04, 2020 at 04:28:47PM +0100, Marco Elver wrote: > > On Tue, 4 Feb 2020 at 15:04, Marco Elver wrote: > > > > > > This adds option KCSAN_ASSUME_PLAIN_WRITES_ATOMIC. If enabled, plain > > > writes up to word size are also assumed to be atomic, and also not > > > subject to other unsafe compiler optimizations resulting in data races. > > > > I just realized we should probably also check for alignedness. Would > > this be fair to add as an additional constraint? It would be my > > preference. > > Checking for alignment makes a lot of sense to me! Otherwise, write > tearing is expected behavior on some systems. Sent v2: http://lkml.kernel.org/r/20200204172112.234455-1-elver@google.com Thanks, -- Marco > Thanx, Paul > > > Thanks, > > -- Marco > > > > > This option has been enabled by default to reflect current kernel-wide > > > preferences. > > > > > > Signed-off-by: Marco Elver > > > --- > > > kernel/kcsan/core.c | 20 +++++++++++++++----- > > > lib/Kconfig.kcsan | 26 +++++++++++++++++++------- > > > 2 files changed, 34 insertions(+), 12 deletions(-) > > > > > > diff --git a/kernel/kcsan/core.c b/kernel/kcsan/core.c > > > index 64b30f7716a12..3bd1bf8d6bfeb 100644 > > > --- a/kernel/kcsan/core.c > > > +++ b/kernel/kcsan/core.c > > > @@ -169,10 +169,19 @@ 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)) > > > + return true; /* Assume all 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 +202,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 +212,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 +470,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 3552990abcfe5..08972376f0454 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,18 @@ 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 writes up to word size are atomic" > > > + default y > > > + help > > > + Assume that plain 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 writes up to word size: > > > + conflicts between marked reads and plain writes up to word size will > > > + not be reported as data races; notice that data races between two > > > + conflicting plain writes will also not be reported. > > > + > > > config KCSAN_IGNORE_ATOMICS > > > bool "Do not instrument marked atomic accesses" > > > help > > > -- > > > 2.25.0.341.g760bfbb309-goog > > >