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=-4.1 required=3.0 tests=BAYES_00,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 AA9A5C433E2 for ; Sat, 5 Sep 2020 16:48:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0BEDE2078E for ; Sat, 5 Sep 2020 16:48:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="IbD/06Lc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0BEDE2078E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 228C16B0003; Sat, 5 Sep 2020 12:48:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D9616B0037; Sat, 5 Sep 2020 12:48:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F0506B0055; Sat, 5 Sep 2020 12:48:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0061.hostedemail.com [216.40.44.61]) by kanga.kvack.org (Postfix) with ESMTP id EE5066B0003 for ; Sat, 5 Sep 2020 12:48:14 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id B22048248047 for ; Sat, 5 Sep 2020 16:48:14 +0000 (UTC) X-FDA: 77229590508.02.name20_5f0f55f270bc Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id 8143210099376 for ; Sat, 5 Sep 2020 16:48:14 +0000 (UTC) X-HE-Tag: name20_5f0f55f270bc X-Filterd-Recvd-Size: 5755 Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Sat, 5 Sep 2020 16:48:14 +0000 (UTC) Received: by mail-lf1-f66.google.com with SMTP id y11so5469599lfl.5 for ; Sat, 05 Sep 2020 09:48:13 -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=fjAYCxwBeXTvhioRg9afO6QjmyeXPyas+z0wHGRGg/02Rf+JVqFcj3h3vLDqWaEYcY tyNS2ThqCPzBLZTUUbANRezwXaHT9Tw6bw2SC5pV281+cIA1eaH2QST7bLg72z7qzCtP VAkKo+yDprdC1ORtEuFfxs8hpjk8Ck9s4ULFP9kvRvavya8f9enA8s6xRc4aBbWKWwqt 3FeSwENxzVjY57pN0gqdkucKZyh7EULpH3fUaWYB0kBB+3VoT+xTsUHLpM+oyF8ZknBd weXpyYRmDWPupCJwyPNKsTtldwlnKIWCkwBLz90Ulz9KfjjZQDI9Fxs9GUB753SKpBKT Vxhw== X-Gm-Message-State: AOAM531+Px9RSghZbChRXvv2i3bJ18+O4ww+fdXzzAYqJhBRfvUpbVqu Sq3m1Asq7lgrvUk/WYEQSlmNskRTofF+5w== X-Google-Smtp-Source: ABdhPJxBe1N0QgXgIVr7QTn2sY1Qs+LPyQ4fOzDJHS2sl3BXhEI481Nm1COWU6wIWEkisBDwwIU7jw== X-Received: by 2002:a19:89d7:: with SMTP id l206mr3291544lfd.110.1599324491867; Sat, 05 Sep 2020 09:48:11 -0700 (PDT) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com. [209.85.167.49]) by smtp.gmail.com with ESMTPSA id f12sm2540671lfp.69.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-f49.google.com with SMTP id z19so5454335lfr.4 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" X-Rspamd-Queue-Id: 8143210099376 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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 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