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=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 E949AFA372C for ; Fri, 8 Nov 2019 18:05:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B6134214DB for ; Fri, 8 Nov 2019 18:05:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573236329; bh=sei9SMQyLHzyMd34U4N8rFdQ0R4Ahh89E73Ax2fCsTg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=ruF3o9VrTHB1B5Fao++YsZ717aYw4JHrXX+G5LSsR5UPcLL1zf9BX+V7PZ6V2O41Z Xa7nCrgVJBi6wOTEtMR01/zLE8+FOvdNNHBQDBJL5nt4BRyPUm8jGDZ/aZBxPy2KGL VhJZPWaweo93meCfnoH37B8i85/NMm1WN8E3Tv1A= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728966AbfKHSF3 (ORCPT ); Fri, 8 Nov 2019 13:05:29 -0500 Received: from mail-lj1-f193.google.com ([209.85.208.193]:46645 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728852AbfKHSF3 (ORCPT ); Fri, 8 Nov 2019 13:05:29 -0500 Received: by mail-lj1-f193.google.com with SMTP id e9so7119641ljp.13 for ; Fri, 08 Nov 2019 10:05:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d9NweSEf4drXt4A6DP1qgzu1cS6gHr1cMfGzVR+7ZWY=; b=BFXx5UUjilC2VGGIFH0qbcrUE/AJuyx2/d46qw2iAAOeTsVx8j2aw2hoCox9tJS3wD paX9fnyjuYtJC19oeyWD/gCxwI2Uq0qQyNq71XhkZ11olv7oacH0v1uAPcX/b+eFj2DD 4IPRZi+crMZ7QCrYaUhsZncB/RosCknDpvqSg= 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=d9NweSEf4drXt4A6DP1qgzu1cS6gHr1cMfGzVR+7ZWY=; b=Nq5YVW3wyRbYN5CCUVxcWvAFL7HCv7i8amnokJ7AOEx99dC9oHn9AyBBE6LuibTCw8 tkgqEAiFNTV8tN44cyCl9fxb962mIaEBJilyct4QTG202MHBqN42OhqVGDaDRfJdM0jU gtX5XVH/arElDsORYxlhzi1171WBtHBZH8otw2oTVM3Yfnr4U13YEavjdSdhNkv0T978 eDNOT2MJlbgpWp5JEbizlgbXuTcTYdnmvd98PbhzV0pJtVZ1oz6UQ6eFMeoDEW3rduPz as5Edy+lb2Bhv0BzkSpknXui6wj96gCeoA+RMa2/j3+q+gMNobzn71DJW9y65o7Qg/pd 1XHQ== X-Gm-Message-State: APjAAAUbavplbAi5KEjnOZRAZMgO9mXmQqY8uR86kMMK4KITOAh6rfOg uPYZPKhGzq7RXkWECHMDlM0AWVsCmxY= X-Google-Smtp-Source: APXvYqxDvkBWmP5qyN0CnS43U1EWAIJaIDIybLoZeWFwW4SbgMvA1jjRlhxLf4q/ltDOsTihCH5/Rg== X-Received: by 2002:a2e:7c10:: with SMTP id x16mr7885440ljc.120.1573236326259; Fri, 08 Nov 2019 10:05:26 -0800 (PST) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com. [209.85.208.173]) by smtp.gmail.com with ESMTPSA id d19sm3069115lfc.12.2019.11.08.10.05.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Nov 2019 10:05:25 -0800 (PST) Received: by mail-lj1-f173.google.com with SMTP id t5so7188955ljk.0 for ; Fri, 08 Nov 2019 10:05:25 -0800 (PST) X-Received: by 2002:a2e:22c1:: with SMTP id i184mr7860520lji.1.1573236324900; Fri, 08 Nov 2019 10:05:24 -0800 (PST) MIME-Version: 1.0 References: <000000000000c422a80596d595ee@google.com> <6bddae34-93df-6820-0390-ac18dcbf0927@gmail.com> In-Reply-To: From: Linus Torvalds Date: Fri, 8 Nov 2019 10:05:08 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: KCSAN: data-race in __alloc_file / __alloc_file To: Eric Dumazet Cc: Eric Dumazet , syzbot , Marco Elver , linux-fsdevel , Linux Kernel Mailing List , syzkaller-bugs , Al Viro 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, 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). > Hmm, which questionable optimization are you referring to? The "avoid dirty cacheline" one by adding a read and a conditional. Yes, it can be an optimization. And it might not be. Linus