From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68566CA9EBC for ; Thu, 24 Oct 2019 11:02:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2A67A20684 for ; Thu, 24 Oct 2019 11:02:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="GSxZTUgn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2A67A20684 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B98736B0005; Thu, 24 Oct 2019 07:02:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B6F956B0006; Thu, 24 Oct 2019 07:02:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AAC216B0007; Thu, 24 Oct 2019 07:02:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0110.hostedemail.com [216.40.44.110]) by kanga.kvack.org (Postfix) with ESMTP id 8B67E6B0005 for ; Thu, 24 Oct 2019 07:02:18 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 319E28151 for ; Thu, 24 Oct 2019 11:02:18 +0000 (UTC) X-FDA: 76078389156.09.jelly44_88643fb1de435 X-HE-Tag: jelly44_88643fb1de435 X-Filterd-Recvd-Size: 5917 Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Thu, 24 Oct 2019 11:02:17 +0000 (UTC) Received: by mail-ot1-f65.google.com with SMTP id z20so1610968otk.10 for ; Thu, 24 Oct 2019 04:02:17 -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=Wp7j55fCu8VBbV3w6xxbpPhvOdRSu/ha8VU4hcpzHdY=; b=GSxZTUgn5T2HRAlKrADzvv53PhUqCr6HGwWIfZ+q0bFeBI/8il22Kv3vpugrhHlUKc JSd3yXOh4TDUfIqO8JPYXGilp4Vg98FIe9l+pL6F5FO2iW7zWgkU28rHfnrJDKC/RUhT 9y7xvvCroceLV28G/DNxI6s3sI/MSBb0LxVcLxj5vL25ilXRyhqWJ+AnuTdwWYD+wKpX O5vqsk+9Nvl/sUnYEZWYKKkmZRx3M69w2mSa0T0GYjtT0TBikdjdIHl9bdIy1avJXFGR mVT16n7Jv0qZPjTSiWzuZVrSqaZmV1oEhg+iVLOxp3SXxbxsxWpuo8R2VJIKx8+2qGRR M+7Q== 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=Wp7j55fCu8VBbV3w6xxbpPhvOdRSu/ha8VU4hcpzHdY=; b=Apq/7aA0zWwI6nvQYG7oJ63uO5SXspk6IPGJ2YgGnb5/1DMDLA4Q2abLWgrK5AVp5Y jMf3vmiwlP7PTe1qk6JKR9ph+0WxrmBgXTWKcRGLzo93EdBenXHoHw2RpYMri/oAqzpo XPJrL21WOX6IayoTz8i6kYnoe7fednXHDDGoQGk8o7jrbtUmncylvvXPS346L1Efl81n J+DpQlJ/Vc98KM3nHkaJETfp8EGiF9tEuuQdEvvdLKvg/MapUjr7pRTgXBEJj0sGSny4 aQBMIPiROC61XM+SrIaPI0eR318/6Op903ScRlRTiwnoV1wqc74LTG8IQn/CnEsMpPZm GeMw== X-Gm-Message-State: APjAAAVtgtuGnrbqtLSw8zXboIL21i0Eo0v0FOTjfxBfkAIOSzKtzuiO r+beHt4Em8ZbUHHdSw/JnfMcY0b6boLklJulBC5rRA== X-Google-Smtp-Source: APXvYqzzXJwi5QeAS4Gnmcn5kNWx1bB+mxOrVbyaL3mIhkaZR6F+nFKJsdPfH9bNhx4bqmlmQAfh3F8piEDK6aQ6BY4= X-Received: by 2002:a9d:82e:: with SMTP id 43mr8537524oty.23.1571914935893; Thu, 24 Oct 2019 04:02:15 -0700 (PDT) MIME-Version: 1.0 References: <20191017141305.146193-1-elver@google.com> <20191017141305.146193-2-elver@google.com> <20191022154858.GA13700@redhat.com> <20191023162432.GC14327@redhat.com> In-Reply-To: <20191023162432.GC14327@redhat.com> From: Marco Elver Date: Thu, 24 Oct 2019 13:02:03 +0200 Message-ID: Subject: Re: [PATCH v2 1/8] kcsan: Add Kernel Concurrency Sanitizer infrastructure To: Oleg Nesterov Cc: LKMM Maintainers -- Akira Yokosawa , Alan Stern , Alexander Potapenko , Andrea Parri , Andrey Konovalov , Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Boqun Feng , Borislav Petkov , Daniel Axtens , Daniel Lustig , Dave Hansen , David Howells , Dmitry Vyukov , "H. Peter Anvin" , Ingo Molnar , Jade Alglave , Joel Fernandes , Jonathan Corbet , Josh Poimboeuf , Luc Maranget , Mark Rutland , Nicholas Piggin , "Paul E. McKenney" , Peter Zijlstra , Thomas Gleixner , Will Deacon , kasan-dev , linux-arch , "open list:DOCUMENTATION" , linux-efi@vger.kernel.org, Linux Kbuild mailing list , LKML , Linux Memory Management List , "the arch/x86 maintainers" Content-Type: text/plain; charset="UTF-8" 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: On Wed, 23 Oct 2019 at 18:24, Oleg Nesterov wrote: > > On 10/22, Marco Elver wrote: > > > > On Tue, 22 Oct 2019 at 17:49, Oleg Nesterov wrote: > > > > > > Just for example. Suppose that task->state = TASK_UNINTERRUPTIBLE, this task > > > does __set_current_state(TASK_RUNNING), another CPU does wake_up_process(task) > > > which does the same UNINTERRUPTIBLE -> RUNNING transition. > > > > > > Looks like, this is the "data race" according to kcsan? > > > > Yes, they are "data races". They are probably not "race conditions" though. > > > > This is a fair distinction to make, and we never claimed to find "race > > conditions" only > > I see, thanks, just wanted to be sure... > > > KCSAN's goal is to find *data races* according to the LKMM. Some data > > races are race conditions (usually the more interesting bugs) -- but > > not *all* data races are race conditions. Those are what are usually > > referred to as "benign", but they can still become bugs on the wrong > > arch/compiler combination. Hence, the need to annotate these accesses > > with READ_ONCE, WRITE_ONCE or use atomic_t: > > Well, if I see READ_ONCE() in the code I want to understand why it was > used. Is it really needed for correctness or we want to shut up kcsan? > Say, why should wait_event(wq, *ptr) use READ_ONCE()? Nevermind, please > forget. > > Btw, why __kcsan_check_watchpoint() does user_access_save() before > try_consume_watchpoint() ? Instrumentation is added in UACCESS regions. Since we do not access user-memory, we do user_access_save to ensure everything is safe (otherwise objtool complains that we do calls to non-whitelisted functions). I will try to optimize this a bit, but we can't avoid it. > Oleg. >