Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp1417818ybk; Thu, 21 May 2020 06:29:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxFb8/QIdNRq4L84O1J+2J3o89SVXFdXX5p4DKPxjvRErbNyRUQ1Xp/QDTtkJq9fV7NBBmO X-Received: by 2002:a50:b286:: with SMTP id p6mr7944436edd.350.1590067789935; Thu, 21 May 2020 06:29:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590067789; cv=none; d=google.com; s=arc-20160816; b=OW3pENTrsEkp00SkdP8ijoI5qinpeHVFzLRVrqBriO4uWgm0zzagQBsaXngwKfFpfP 4vE+0BU9cB4GWM/hv0lbXwNTgfI/CEqHO1Ky90OZPem9PxKxNf3gATduiZyKmiUw0JAK 1OWD5rtVFbFHE0IRhrDgWdCYGIhYLspFIMlrZiQMkGjFNU8llraG2vRWXxFUSW2TZsZb gytdAonazRmR2jWr+6Ge6ytqCrFl5PXw2dFOihsV45OZsCXNCeOv2eHcl9eS+UQL7g0P bh7/JZRAF9YDPy4/vnFZHnP5STRJQcNFLd7vjgvXokrAEbfQKNnd6gUfOE9fPzy/vnYY Gsmg== 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=Moc8xalnKllIyEU4EMIrwAPrYnUw5Fl91QeBkTIQAoU=; b=EOv2QDHKmFAMAdhm0oZRdcNHdoBXuafqzVSZy87sbIM1Iymp0FyJyPZf93GEDoH91Y dMmoY/ZaBEzgLuyZeigxnQ1q11LRJ8tdkswyi1qagJofqlg1FUjXotrr36xcy+nt2xyJ vYpJzaBaIIYqcgHVRT/CkgdYcwv3vQoNpj21d96igliVTTgtamfqcu1Ur/C2u4fyETQv M38BdzT/7YL0Hk3KB2MP6EvSLhCEnmF8w7dfJjrot6Gc92PrWJAa9Kf3zXKuovmck+nt gdGkh2q/0GY2a0T2AasH04xxSKspl4zcxiTsHOufQffUcTuzt7AsQ+GQiqZYLuD9ABlN wCZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=GXlGtQiQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id f12si2935417edl.157.2020.05.21.06.29.25; Thu, 21 May 2020 06:29:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=GXlGtQiQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1729425AbgEUN1D (ORCPT + 99 others); Thu, 21 May 2020 09:27:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45000 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729197AbgEUN1D (ORCPT ); Thu, 21 May 2020 09:27:03 -0400 Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0A6C1C061A0E for ; Thu, 21 May 2020 06:27:03 -0700 (PDT) Received: by mail-ot1-x341.google.com with SMTP id v17so5523240ote.0 for ; Thu, 21 May 2020 06:27:03 -0700 (PDT) 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=Moc8xalnKllIyEU4EMIrwAPrYnUw5Fl91QeBkTIQAoU=; b=GXlGtQiQaxvoKjPhENuW0Yo48zaUNh8OYTsBNf5sIYxfYJMM7j5rAKAGmJxEYsu5o/ XKwVa8BGYWdWTkZpRNcHr1kt6CoaDsL41XAhLXyRuuxC2zaRkTkiTRHgezKsr6xh7i3U Jeizwmzq/m3u/7DKGSwYzWVlCQNURvQAG6PFIrrWLi+lBS14IiAVGLr+uTxrwDn7j8P6 ZXewMF/LMvF5NCAsDXCW3Fo08pBQynl+f5jzwblurJnUCjgKiA1u9BnaANrcfrQs1klZ SXqK5fpmbfRGbbmodC6eJgbYX2VccAEwqxwj4C0HB+eU2co6lDDf8RdlAU2733umcqo8 +SBg== 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=Moc8xalnKllIyEU4EMIrwAPrYnUw5Fl91QeBkTIQAoU=; b=HTZF6fZfEKrCk+pRzAJpXNthfY5EFqJcOz3R3Yjyf/zPwPY2qTOeZV3gxTgoNdxNqY MMTHUJ+CcOJYJ27Wx9FT/EWHZlE1ON7+LTUZMVolBpSvCEsm4YAdAE/7u/FoAKvD6kAd g4HmSoRx76a2iMeYLobFe10s1T4kHW/4+nq2YRVL4Kl8AEPSTtJdYmrjDAsyMa4cFwHU he4kGD/CwU5gBaw5c7vEka2lDidlFbjEcX0SuEDDVJxvEQdBBE/0/9z34qigGpO0EXui BgnboWo2P25XP//gITAFtoh8MCG/bdonuuHmz2mYenCIJhUEKM89NCgk0gn+qk1i1PNh hZig== X-Gm-Message-State: AOAM531jfQD1K4pHZ9lb+ojTtgUIDBHSHKVlVREr2Kz/Om1ndc9LzK6k eYj7+yMD2H34vqdjA39OcgHXXpua8QDTCNV+9JW1Ew== X-Received: by 2002:a05:6830:18ce:: with SMTP id v14mr6550417ote.251.1590067622152; Thu, 21 May 2020 06:27:02 -0700 (PDT) MIME-Version: 1.0 References: <20200521110854.114437-1-elver@google.com> <20200521110854.114437-4-elver@google.com> <20200521131803.GA6608@willie-the-truck> In-Reply-To: <20200521131803.GA6608@willie-the-truck> From: Marco Elver Date: Thu, 21 May 2020 15:26:48 +0200 Message-ID: Subject: Re: [PATCH -tip v2 03/11] kcsan: Support distinguishing volatile accesses To: Will Deacon Cc: "Paul E. McKenney" , Dmitry Vyukov , Alexander Potapenko , Andrey Konovalov , kasan-dev , LKML , Thomas Gleixner , Ingo Molnar , Peter Zijlstra , clang-built-linux , Borislav Petkov 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 Thu, 21 May 2020 at 15:18, Will Deacon wrote: > > On Thu, May 21, 2020 at 01:08:46PM +0200, Marco Elver wrote: > > In the kernel, volatile is used in various concurrent context, whether > > in low-level synchronization primitives or for legacy reasons. If > > supported by the compiler, we will assume that aligned volatile accesses > > up to sizeof(long long) (matching compiletime_assert_rwonce_type()) are > > atomic. > > > > Recent versions Clang [1] (GCC tentative [2]) can instrument volatile > > accesses differently. Add the option (required) to enable the > > instrumentation, and provide the necessary runtime functions. None of > > the updated compilers are widely available yet (Clang 11 will be the > > first release to support the feature). > > > > [1] https://github.com/llvm/llvm-project/commit/5a2c31116f412c3b6888be361137efd705e05814 > > [2] https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544452.html > > > > This patch allows removing any explicit checks in primitives such as > > READ_ONCE() and WRITE_ONCE(). > > > > Signed-off-by: Marco Elver > > --- > > v2: > > * Reword Makefile comment. > > --- > > kernel/kcsan/core.c | 43 ++++++++++++++++++++++++++++++++++++++++++ > > scripts/Makefile.kcsan | 5 ++++- > > 2 files changed, 47 insertions(+), 1 deletion(-) > > > > diff --git a/kernel/kcsan/core.c b/kernel/kcsan/core.c > > index a73a66cf79df..15f67949d11e 100644 > > --- a/kernel/kcsan/core.c > > +++ b/kernel/kcsan/core.c > > @@ -789,6 +789,49 @@ void __tsan_write_range(void *ptr, size_t size) > > } > > EXPORT_SYMBOL(__tsan_write_range); > > > > +/* > > + * Use of explicit volatile is generally disallowed [1], however, volatile is > > + * still used in various concurrent context, whether in low-level > > + * synchronization primitives or for legacy reasons. > > + * [1] https://lwn.net/Articles/233479/ > > + * > > + * We only consider volatile accesses atomic if they are aligned and would pass > > + * the size-check of compiletime_assert_rwonce_type(). > > + */ > > +#define DEFINE_TSAN_VOLATILE_READ_WRITE(size) \ > > + void __tsan_volatile_read##size(void *ptr) \ > > + { \ > > + const bool is_atomic = size <= sizeof(long long) && \ > > + IS_ALIGNED((unsigned long)ptr, size); \ > > + if (IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS) && is_atomic) \ > > + return; \ > > + check_access(ptr, size, is_atomic ? KCSAN_ACCESS_ATOMIC : 0); \ > > + } \ > > + EXPORT_SYMBOL(__tsan_volatile_read##size); \ > > + void __tsan_unaligned_volatile_read##size(void *ptr) \ > > + __alias(__tsan_volatile_read##size); \ > > + EXPORT_SYMBOL(__tsan_unaligned_volatile_read##size); \ > > + void __tsan_volatile_write##size(void *ptr) \ > > + { \ > > + const bool is_atomic = size <= sizeof(long long) && \ > > + IS_ALIGNED((unsigned long)ptr, size); \ > > + if (IS_ENABLED(CONFIG_KCSAN_IGNORE_ATOMICS) && is_atomic) \ > > + return; \ > > + check_access(ptr, size, \ > > + KCSAN_ACCESS_WRITE | \ > > + (is_atomic ? KCSAN_ACCESS_ATOMIC : 0)); \ > > + } \ > > + EXPORT_SYMBOL(__tsan_volatile_write##size); \ > > + void __tsan_unaligned_volatile_write##size(void *ptr) \ > > + __alias(__tsan_volatile_write##size); \ > > + EXPORT_SYMBOL(__tsan_unaligned_volatile_write##size) > > + > > +DEFINE_TSAN_VOLATILE_READ_WRITE(1); > > +DEFINE_TSAN_VOLATILE_READ_WRITE(2); > > +DEFINE_TSAN_VOLATILE_READ_WRITE(4); > > +DEFINE_TSAN_VOLATILE_READ_WRITE(8); > > +DEFINE_TSAN_VOLATILE_READ_WRITE(16); > > Having a 16-byte case seems a bit weird to me, but I guess clang needs this > for some reason? Yes, the emitted fixed-size instrumentation is up to 16 bytes, so we'll need it (for both volatile and non-volatile -- otherwise we'll get linker errors). It doesn't mean we'll consider 16 byte volatile accesses as atomic, because of the size check to compute is_atomic above. Thanks, -- Marco