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,URIBL_BLOCKED,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 6CD38C47E49 for ; Tue, 22 Oct 2019 17:43:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 10B5F20B7C for ; Tue, 22 Oct 2019 17:43:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="D8bfP3dY" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 10B5F20B7C 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 A31266B000E; Tue, 22 Oct 2019 13:43:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E1636B026C; Tue, 22 Oct 2019 13:43:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F7786B026D; Tue, 22 Oct 2019 13:43:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0043.hostedemail.com [216.40.44.43]) by kanga.kvack.org (Postfix) with ESMTP id 69D9B6B000E for ; Tue, 22 Oct 2019 13:43:03 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id DEC8683E2 for ; Tue, 22 Oct 2019 17:43:02 +0000 (UTC) X-FDA: 76072141404.06.coach74_1a8982339de04 X-HE-Tag: coach74_1a8982339de04 X-Filterd-Recvd-Size: 7723 Received: from mail-oi1-f194.google.com (mail-oi1-f194.google.com [209.85.167.194]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Tue, 22 Oct 2019 17:43:02 +0000 (UTC) Received: by mail-oi1-f194.google.com with SMTP id x3so14963527oig.2 for ; Tue, 22 Oct 2019 10:43:02 -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=MHo+bPZ3FyZTrXrvFae5gOHqYffPj0NYcnQ23J1Mtd8=; b=D8bfP3dYb9Xw3Ejz/XW6sJaiJoIzrU0if9m7dseFDXz0GuoQXFZZBSTgbjJU0sjON7 CTsIv3bjWf2AvHSPeKOaRXcyEjBAx+URak3jnpv4lulJ/EVuiqqWnNdoWoe554TF/cJ0 FU8/9VTLt4e6HnKwcSlzNGR54imzjgAORjvN05VsZdT3aFYiGR+7MO+6zvojPCzmaXQe rqmerCdhyIjHFH+noVK7tj/FkhNO4aAZ0Up4wIhGTOOBiYn85Qd1A+J2olHu9J0wWQTq mFpeecULEnrKhZxONseYGkjQ356U0Iwm1ionhs0PmWk/gwCIyyzyxv1w+qkcqY7dnMsh p2hw== 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=MHo+bPZ3FyZTrXrvFae5gOHqYffPj0NYcnQ23J1Mtd8=; b=PrVehrG/mE6pJ628IO9UkR5JOwMPV8X8oKFA54zl4m8z0QJijMxPmJNWNdsQIJz5Bs 21tUTaV1COtmg3Vc3+PNHK4TC//nfvu6oe8b8/6Kpb8xDdBzfkvQCtf82bQo/aJShbLF bCjk7HO7RFN28/6tBokICXhvIwidndiUgwacce3Ecf9o7Gs21dyyO1irT01bS+2DJ8cN jjR17JmWlmUBh0YjwFiiuugvAzsiohpn6XoyV9OUtnNZo39g/QfC/XBhLvVzjf5XBPUK VdxdT8p74B9iIJSEgiYGapEgCiSp6c4OExzSE4meq2FLVNvgGWCoPSDRdv3wIypZWLwf 0zQw== X-Gm-Message-State: APjAAAUMwKsLyPRWdIvoZpXWA6s/A4Z0F+BZ6vWpPEBBtWHjsfIf2OHw OOPUcnrwyROViJ+zSHSFOLr5epYp0KFySEkOqREIJQ== X-Google-Smtp-Source: APXvYqxfVwLHQu/nljm2npVYMv0/xxXLHw8hKdDqlhGb7PXQz9eRPAcgKMk0ub1hWAYFfjq7ip3as3hOP5jSlLN4VGw= X-Received: by 2002:aca:f492:: with SMTP id s140mr4056153oih.83.1571766180963; Tue, 22 Oct 2019 10:43:00 -0700 (PDT) MIME-Version: 1.0 References: <20191017141305.146193-1-elver@google.com> <20191017141305.146193-2-elver@google.com> <20191022154858.GA13700@redhat.com> In-Reply-To: <20191022154858.GA13700@redhat.com> From: Marco Elver Date: Tue, 22 Oct 2019 19:42:48 +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 Tue, 22 Oct 2019 at 17:49, Oleg Nesterov wrote: > > On 10/17, Marco Elver wrote: > > > > + /* > > + * Delay this thread, to increase probability of observing a racy > > + * conflicting access. > > + */ > > + udelay(get_delay()); > > + > > + /* > > + * Re-read value, and check if it is as expected; if not, we infer a > > + * racy access. > > + */ > > + switch (size) { > > + case 1: > > + is_expected = expect_value._1 == READ_ONCE(*(const u8 *)ptr); > > + break; > > + case 2: > > + is_expected = expect_value._2 == READ_ONCE(*(const u16 *)ptr); > > + break; > > + case 4: > > + is_expected = expect_value._4 == READ_ONCE(*(const u32 *)ptr); > > + break; > > + case 8: > > + is_expected = expect_value._8 == READ_ONCE(*(const u64 *)ptr); > > + break; > > + default: > > + break; /* ignore; we do not diff the values */ > > + } > > + > > + /* Check if this access raced with another. */ > > + if (!remove_watchpoint(watchpoint)) { > > + /* > > + * No need to increment 'race' counter, as the racing thread > > + * already did. > > + */ > > + kcsan_report(ptr, size, is_write, smp_processor_id(), > > + kcsan_report_race_setup); > > + } else if (!is_expected) { > > + /* Inferring a race, since the value should not have changed. */ > > + kcsan_counter_inc(kcsan_counter_races_unknown_origin); > > +#ifdef CONFIG_KCSAN_REPORT_RACE_UNKNOWN_ORIGIN > > + kcsan_report(ptr, size, is_write, smp_processor_id(), > > + kcsan_report_race_unknown_origin); > > +#endif > > + } > > Not sure I understand this code... > > 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 -- race conditions are logic bugs that result in bad state due to unexpected interleaving of threads. Data races are more subtle, and become relevant at the programming language level. In Documentation we summarize: "Informally, two operations conflict if they access the same memory location, and at least one of them is a write operation. In an execution, two memory operations from different threads form a data-race if they conflict, at least one of them is a *plain* access (non-atomic), and they are unordered in the "happens-before" order according to the LKMM." 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: - https://lwn.net/Articles/793253/ - https://lwn.net/Articles/799218/ > Hmm. even the "if (!(p->state & state))" check in try_to_wake_up() can trigger > kcsan_report() ? We blacklisted sched (KCSAN_SANITIZE := n in kernel/sched/Makefile), so these data races won't actually be reported. Thanks, -- Marco > Oleg. >