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 5BA79FA372C for ; Fri, 8 Nov 2019 18:16:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 304AD21882 for ; Fri, 8 Nov 2019 18:16:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="eOjJlMG+" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729373AbfKHSQQ (ORCPT ); Fri, 8 Nov 2019 13:16:16 -0500 Received: from mail-oi1-f194.google.com ([209.85.167.194]:41577 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728124AbfKHSQL (ORCPT ); Fri, 8 Nov 2019 13:16:11 -0500 Received: by mail-oi1-f194.google.com with SMTP id e9so6040078oif.8 for ; Fri, 08 Nov 2019 10:16:10 -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=5tUkPEobvq0D1LVe3HBgFyeSBazbNDJmhpV7AqtazYk=; b=eOjJlMG++cIiJCf+41ocgxmN10k5xlvB3wJ0CksO002FTLGIfa1fJAK3O6Jkuvb+fx PoYCLNW6D9YGSl/MRBgAgccJM9ZYaMcSWBKOR7v209fCgig2SLt9Ica4sc8EHdCSh8XH Ux1kOwoLofwMYcXkC1qfLwNF+V8nJ+gsHx/B6VSj99yDTpBiHFF7QN7BQjdI0F/qpINc 9OuIsii0Utk16W6qPPnOPqVSFO9J2+ryFGyMIdT+r6lw0e2eERLZDQDBX+lKlXDdfOG5 5aoWOUYIE9AeSKenvkd6IZDEUieVABlwMtLu3qTnx16lM/SXZWP7UC29idEKMbV/UIQM LPug== 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=5tUkPEobvq0D1LVe3HBgFyeSBazbNDJmhpV7AqtazYk=; b=EJzJzIuJArH00+w56Wx24ysa6DzQay2fECnKtaWiEnaeTSDdP9mkkA7YF1rOOf5Srd n0Ub+chpbrUKU/Kn/JO8QUgSG/VPe15Ei4d86qZBf7tox8Mdfmmj9CSsr1nJjF1fIVQf vuBRq/mX++tZ90A4XXheyhAnuI189pBrzfWfB6b7/e0yrzca4pCw/+kNxMO36feR/6ed V8FpcR+GB+p2bG/vmGJA9IpiurSrKPlACnvarXNnxf+6dkTC4DJLeihrNE/ZmtkKB5Sn BxVJg5zMHhJEGkAn3qn20h3ZfMbnvgPM+xQ2/DnfPrW34ip/3+1AF8RoUOjjMXEueSeq y1lw== X-Gm-Message-State: APjAAAXjJGlOjIhv3esmItwvQ+YnFt9wTKSc2ymk5mXcIY4isGvmStTM rYYe0XiVvJgOokBGrbQTbDg12bWG2RaHaxUl8Lc7DA== X-Google-Smtp-Source: APXvYqxRJMUbSON3GrNlz4n2lBEX4xlXNxzvn2DMVWHU2QEnT8Nd2kjm7NF/1I3KGh6JRBri/HehhFEFXd1Cw4pZHpY= X-Received: by 2002:aca:fc0d:: with SMTP id a13mr10989363oii.83.1573236969814; Fri, 08 Nov 2019 10:16:09 -0800 (PST) MIME-Version: 1.0 References: <000000000000c422a80596d595ee@google.com> <6bddae34-93df-6820-0390-ac18dcbf0927@gmail.com> In-Reply-To: From: Marco Elver Date: Fri, 8 Nov 2019 19:15:58 +0100 Message-ID: Subject: Re: KCSAN: data-race in __alloc_file / __alloc_file To: Linus Torvalds Cc: Eric Dumazet , Eric Dumazet , syzbot , linux-fsdevel , Linux Kernel Mailing List , syzkaller-bugs , Al Viro , Alan Stern , Andrea Parri , "Paul E. McKenney" , LKMM Maintainers -- Akira Yokosawa Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Fri, 8 Nov 2019 at 19:05, Linus Torvalds wrote: > > On Fri, Nov 8, 2019 at 9:53 AM Eric Dumazet wrote: > > > > I personally like WRITE_ONCE() since it adds zero overhead on generated code, > > and is the facto accessor we used for many years (before KCSAN was conceived) > > So I generally prefer WRITE_ONCE() over adding "volatile" to random > data structure members. > > Because volatile *does* have potentially absolutely horrendous > overhead on generated code. It just happens to be ok for the simple > case of writing once to a variable. > > In fact, you bring that up yourself in your next email when you ask > for "ADD_ONCE()". Exactly because gcc generates absolutely horrendous > garbage for volatiles, for no actual good reason. Gcc *could* generate > a single add-to-memory instruction. But no, that's not at all what gcc > does. > > So for the kernel, we've generally had the rule to avoid 'volatile' > data structures as much as humanly possible, because it actually does > something much worse than it could do, and the source code _looks_ > simple when the volatile is hidden in the data structures. > > Which is why we have READ_ONCE/WRITE_ONCE - it puts the volatile in > the code, and makes it clear not only what is going on, but also the > impact it has on code generation. > > But at the same time, I don't love WRITE_ONCE() when it's not actually > about writing once. It might be better to have another way to show > "this variable is a flag that we set to a single value". Even if maybe > the implementation is then the same (ie we use a 'volatile' assignment > to make KCSAN happy). (+some LKMM folks, in case I missed something on what the LKMM defines as data race.) KCSAN does not use volatile to distinguish accesses. Right now READ_ONCE, WRITE_ONCE, atomic bitops, atomic_t (+ some arch specific primitives) are treated as marked atomic operations. The goal is to cover all primitives that the LKMM declares as marked/atomic. A data race is then detected for concurrent conflicting accesses where at least one is plain unmarked. In the end the LKMM should decide what KCSAN determines as a data race. As far as I can tell, none of the reported data races so far are false positives in that sense. Many thanks, -- Marco