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,URIBL_BLOCKED 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 684DBC43331 for ; Sun, 10 Nov 2019 19:21:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3C88A20854 for ; Sun, 10 Nov 2019 19:21:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573413675; bh=fsQV/vIJseysmHIBSbuAF5psHRmutlyROOzFy00FGtU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=gqWjFzlrXzHQ/jFHk3hCqwYv1wQI1CcauHHNeQEsI4b5/Awj6WwdtXW0ZbTJP0b7a lXyLAg9FUY5vKVXDn+eA/5QjNob2RlABGJm3LlAjHlZwOqyw0oPog7Ex8gXQHUYvGQ WxmRW5wRndJ1tzSAmuZQqilc2FocXogbQCGYT40g= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726900AbfKJTVO (ORCPT ); Sun, 10 Nov 2019 14:21:14 -0500 Received: from mail-lf1-f50.google.com ([209.85.167.50]:34487 "EHLO mail-lf1-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726832AbfKJTVO (ORCPT ); Sun, 10 Nov 2019 14:21:14 -0500 Received: by mail-lf1-f50.google.com with SMTP id y186so2370994lfa.1 for ; Sun, 10 Nov 2019 11:21:13 -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=vps6XmCw9WRkAtYxpnFwWu+xV4X8ojukCSN0qo58N6c=; b=cIj419uq1cCoNo/Cqt9dnkfZ/zoLO/cAgHHpjyVkn/Tj0px/QPbQk8+nmQiG4RBzYX /DhDmmagDbgLBwtfJUZexOqqGEfiZJNMQDyi3dPKp2PfVpw/BsJT01SEfki1eU0+DTUe IuZxYN2U4SUb4pI+OIgnz5/kkESeGNQ+VYBVY= 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=vps6XmCw9WRkAtYxpnFwWu+xV4X8ojukCSN0qo58N6c=; b=LUJJCRPgbcJmvshETGJ+o7e0918gT4bCTLvWrapSM+/TG5UtlSdM8zdp9PoGz6kU6C 2VUGMEre0KSBn9aNu1LIyp/JNhHcezvrQWroH1Y3OS+3LjyOrovWof4YzsNPtpCcNsPt xuoLvHLRMOjbS9L3iSUIcWlGRuNjCgrl5euXDKbiUVn+R6OGE/1qiz5aG8s9i2vGkhO7 /f/NPHbI80fsL2TZ3p2ueMPFznJAw602wZlASHLndFYeqlmLltFiGA2MBT/PusqQs6mC PX6cf3t/z+urroCSFxDOmRChXD9hKpx9wXkuWb34+oQ1adOUJRSs1ZNuKO7/YeJq5CC0 7g5Q== X-Gm-Message-State: APjAAAXhXKbX2ANToSDObcfPcjrT8rVX9hS7XDuCSVmMCWNfyd9n6OMg sGjZawdXgEra7G4eIrqS4Mfw5GESkJg= X-Google-Smtp-Source: APXvYqwLnlmaGGMqCdi+jvuXb4Xa8A4z45uak6vvGriTKSKbmLyUbkl4GS+L4LV/SPV6fviVFKaweQ== X-Received: by 2002:a19:651b:: with SMTP id z27mr12796185lfb.117.1573413671461; Sun, 10 Nov 2019 11:21:11 -0800 (PST) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com. [209.85.167.49]) by smtp.gmail.com with ESMTPSA id t28sm3319756ljd.47.2019.11.10.11.21.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 Nov 2019 11:21:10 -0800 (PST) Received: by mail-lf1-f49.google.com with SMTP id y186so2370959lfa.1 for ; Sun, 10 Nov 2019 11:21:09 -0800 (PST) X-Received: by 2002:ac2:498a:: with SMTP id f10mr1217684lfl.170.1573413669634; Sun, 10 Nov 2019 11:21:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Sun, 10 Nov 2019 11:20:53 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: KCSAN: data-race in __alloc_file / __alloc_file To: Alan Stern Cc: Marco Elver , Eric Dumazet , Eric Dumazet , syzbot , linux-fsdevel , Linux Kernel Mailing List , syzkaller-bugs , Al Viro , 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 Sun, Nov 10, 2019 at 11:12 AM Linus Torvalds wrote: > > And this is where WRITE_IDEMPOTENT would make a possible difference. > In particular, if we make the optimization to do the "read and only > write if changed" It might be useful for checking too. IOW, something like KCSAN could actually check that if a field has an idempotent write to it, all writes always have the same value. Again, there's the issue with lifetime. Part of that is "initialization is different". Those writes would not be marked idempotent, of course, and they'd write another value. There's also the issue of lifetime at the _end_ of the use, of course. There _are_ interesting data races at the end of the lifetime, both reads and writes. In particular, if it's a sticky flag, in order for there to not be any races, all the writes have to happen with a refcount held, and the final read has to happen after the final refcount is dropped (and the refcounts have to have atomicity and ordering, of course). I'm not sure how easy something like that is model in KSAN. Maybe it already does things like that for all the other refcount stuff we do. But the lifetime can be problematic for other reasons too - in this particular case we have a union for that sticky flag (which is used under the refcount), and then when the final refcount is released we read that value (thus no data race) but because of the union we will now start using that field with *different* data. It becomes that RCU list head instead. That kind of "it used to be a sticky flag, but now the lifetime of the flag is over, and it's something entirely different" might be a nightmare for something like KCSAN. It sounds complicated to check for, but I have no idea what KCSAN really considers complicated or not. Linus