Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp2138524pxk; Sat, 5 Sep 2020 09:50:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyyld6Se+c8F4VN+HGlby8srlKzRKWyQCI4921fhOsA+aPS2aMFuwgDua96tBouHAP6nFuS X-Received: by 2002:a50:e80a:: with SMTP id e10mr14540103edn.4.1599324622873; Sat, 05 Sep 2020 09:50:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599324622; cv=none; d=google.com; s=arc-20160816; b=LjF01iKzLNnhAam4fEmH1TXOGc2ok/BS87hzLDL3uBArKnxoFN7jZTem3hfo4xsTu6 Z4feNAjnpY5TMyMof9edbz0VC/QvKPsDNjonJm27sswn/F9DtilUOlsvlBJYkLqq4B0F F78yAVJRoLLR7qHfiR1gb79jftKNd6vpjjhsEQBXN13x6R5vDvYWcHIWD1IKOKe7bMO+ 4lSMOotEQiXq2ZbLpDlIHFXX9NY8AuJZjFNzLbgDC75dlJ6zWZmPrsVNuvDRUoZYlewf G+0DApzKgvhTx6+W+WD/m791exJM6EkiErsESK+anZCH+ykve7jPDB10gC+T/6iD2V1U p+8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=WiPzQYToprkedvPvy23+d8Sogck/PPDXaDM0aINUTxs=; b=Yit2IxAOn7NKDgZLorAeSgdI86+BdNd9MEEtDx7Zo+rnidvQjoTBN/U/N+1iODgZIU maRVx0geqmzbzHFkV/MU9vzG9szT/MdzZN9Rw9sf8V86b0P+Q4RPTofC9zsJOBRC4oi7 9ip9q4e3l8nPK4IPFeAFipR2RiGpqlz6QvbaZA9bT9fscx5EBlJdfGac/bYfonap/sMC 9tcjmJgVAELwWTPyn7cyyfIHK+qzL7dgbh2ptXPM/EExV470i66IebPbviMWzalKhRLb iwAa+53kyWFk1Q80dFH5djlChbZJQSBdjtzVG3NkY9Uf8N4o8PMwddR8AbFhKUJwAFxU aQQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b="IbD/06Lc"; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r6si7308362edb.217.2020.09.05.09.49.49; Sat, 05 Sep 2020 09:50:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b="IbD/06Lc"; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726568AbgIEQsT (ORCPT + 99 others); Sat, 5 Sep 2020 12:48:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47752 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727875AbgIEQsP (ORCPT ); Sat, 5 Sep 2020 12:48:15 -0400 Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D4F80C061244 for ; Sat, 5 Sep 2020 09:48:14 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id n25so506982ljj.4 for ; Sat, 05 Sep 2020 09:48:14 -0700 (PDT) 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=WiPzQYToprkedvPvy23+d8Sogck/PPDXaDM0aINUTxs=; b=IbD/06LcWNINiD1qQx76yuC4NnGDIsm3+GWIOtgRCjshaVtDI/A02DI5qKetncQ5Eq ETJ/AP0MURo4tMxU2BWA9ZqY9wz8byBe5Nb/ZFb/npAfuJhH/nO2eJvqX1EnmPNcLt9a /DIWjA8HitbuHHT5Zgo8zabEuZouEGY3xlN9Q= 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=WiPzQYToprkedvPvy23+d8Sogck/PPDXaDM0aINUTxs=; b=HTHdUXkzonzyqZk4Q8lIBIgrmRgmT+T7sw3PvPZZ/dMCk+hrXZ4hkNpDM2+Oyc3ur6 T7toe7WJNMAiBLKMMpblobdlpPBSD4yoDfee+LhZ1OhywiC49pIvdQ3npJkGBwPiQD+w Lnsrq2/d2BTsuj9PSXIW0QC5TEiospibutaPBhbq6KOcyPt0IV9Em+5YoAB+Jea2feNa RxDVZkVYMfZgZT8bI4FJaC0LHR/207hEZP/yyEFSRG7TJ1yQlINMHwNkeLY0PtML+bN9 v/jBmoabu9Isd4/rJPaed/Ad62KWIX3/dJWvbC+1NoElP+6+CDWdxS3XydLV0MHigZ+6 m+GQ== X-Gm-Message-State: AOAM530iUIlZ3GSnG/zfN5z3RsyB6Ap/C4dy5yfDm+ZbXQ7CSl3FOpql ERQPbYJEepZp/Cl4wYU7d4R6YEJfQk999w== X-Received: by 2002:a05:651c:32b:: with SMTP id b11mr923175ljp.99.1599324492101; Sat, 05 Sep 2020 09:48:12 -0700 (PDT) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com. [209.85.167.54]) by smtp.gmail.com with ESMTPSA id i12sm2545188lfi.48.2020.09.05.09.48.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Sep 2020 09:48:10 -0700 (PDT) Received: by mail-lf1-f54.google.com with SMTP id y17so5446867lfa.8 for ; Sat, 05 Sep 2020 09:48:09 -0700 (PDT) X-Received: by 2002:a19:c8c6:: with SMTP id y189mr6480035lff.125.1599324489251; Sat, 05 Sep 2020 09:48:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Sat, 5 Sep 2020 09:47:53 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/2] xfs: don't update mtime on COW faults To: Mikulas Patocka Cc: Jan Kara , "Darrick J. Wong" , Dave Chinner , Jann Horn , Christoph Hellwig , Oleg Nesterov , Kirill Shutemov , "Theodore Ts'o" , Andrea Arcangeli , Matthew Wilcox , Andrew Morton , Dan Williams , Linux-MM , Linux Kernel Mailing List , linux-nvdimm , Ext4 Developers List , linux-xfs Content-Type: text/plain; charset="UTF-8" Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Sat, Sep 5, 2020 at 5:13 AM Mikulas Patocka wrote: > > When running in a dax mode, if the user maps a page with MAP_PRIVATE and > PROT_WRITE, the xfs filesystem would incorrectly update ctime and mtime > when the user hits a COW fault. So your patch is obviously correct, but at the same time I look at the (buggy) ext2/xfs code you fixed, and I go "well, that was a really natural mistake to make". So I get the feeling that "yes, this was an ext2 and xfs bug, but we kind of set those filesystems up to fail". Could this possibly have been avoided by having nicer interfaces? Grepping around, and doing a bit of "git blame", I note that ext4 used to have this exact same bug too, but it was fixed three years ago in commit fd96b8da68d3 ("ext4: fix fault handling when mounted with -o dax,ro") and nobody at the time clearly realized it might be a pattern. And honestly, it's possible that the pattern came from cut-and-paste errors, but it's equally likely that the pattern was there simply because it was such a natural pattern and such an easy and natural mistake to make. Maybe it's inevitable. Some people do want (and need) the information whether it was a write just because they care about the page table issues (ie marking the pte dirty etc). To that kind of situation, whether it's shared or not might not matter all that much. But to a filesystem, a private write vs a shared write are quite different things. So I don't really have any suggestions, and maybe it's just what it is, but maybe somebody has an idea for how to make it slightly less natural to make this mistake.. But maybe just a test-case is all it takes, like Darrick suggests. Linus