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=-3.9 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,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 90B6CC43465 for ; Mon, 21 Sep 2020 16:20:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 075A622574 for ; Mon, 21 Sep 2020 16:20:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="RFMB/gNw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 075A622574 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 299A390008F; Mon, 21 Sep 2020 12:20:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2499690008B; Mon, 21 Sep 2020 12:20:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 13AE690008F; Mon, 21 Sep 2020 12:20:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0166.hostedemail.com [216.40.44.166]) by kanga.kvack.org (Postfix) with ESMTP id ED62590008B for ; Mon, 21 Sep 2020 12:20:50 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id AB083181AC9BF for ; Mon, 21 Sep 2020 16:20:50 +0000 (UTC) X-FDA: 77287582260.10.rub26_4707d3227146 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id 97C3A16A06B for ; Mon, 21 Sep 2020 16:20:49 +0000 (UTC) X-HE-Tag: rub26_4707d3227146 X-Filterd-Recvd-Size: 6145 Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Mon, 21 Sep 2020 16:20:49 +0000 (UTC) Received: by mail-lf1-f68.google.com with SMTP id b12so14681161lfp.9 for ; Mon, 21 Sep 2020 09:20:48 -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=f8LK5dloOXhiAuv1jzPTpg6aj5g8mwVrNmUPAV9ogWY=; b=RFMB/gNwPwfIqudW3R4jXCFsXqrNlGTxVuJ7YvVxCKzq5Y/YUC/Ma6uY7s95wRftZ1 7s8sQIj4iiCqfqYdGopoS/gZplkdWgCmkY2aCa/c5cevLuamU4HpSU0quOZvV2Xv5EaL vunDI/0xHWZgKhUbEF4U4wC7LUJxngCiHSvxU= 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=f8LK5dloOXhiAuv1jzPTpg6aj5g8mwVrNmUPAV9ogWY=; b=UTovHwEgWCBnEB45tx8AckJVjNoy0U8zVQPk6+fDk1NKM3NZfzWzts2och5l9H+09n EYt0yWyPjg7HXANGxPhiqhhWS/uo9TOhvKLPB9gWe+8qt9OsFnCMvzZQy05puHcY6d4k 6/62z3MvsCdm0X0DXIPaQfz0JSxOQMY+0p9OdXHg32FKtE6UhlkUcs7hjEnWn2e1Txor rVXaoDPLrEeXQOFCTstxn6Q08Uu67Zd0Hncsw1ekncaUZzGmsh5WpPEsJW73tZm6CAro i14nGK6ntBjFdx8xQQ0P5VB6dOJupwulNPwa7cZSkbBkThJz0HMQyIjqsTSjyR/S4ApS T79A== X-Gm-Message-State: AOAM531O3qvMymvBw2BSc58GcgPIx/WDXKk8DjdlNfRHFi9x6oAkbxkO QpDpgz2UWdYrwIBG5Tef4fb+rtmFTknLfQ== X-Google-Smtp-Source: ABdhPJz6gA0YznwVbfqM+mQCo35AXEo/t21ZtCCdcBDtlnjlrl6VPAAmyBppf5ecfJu9MTxngFOELw== X-Received: by 2002:a19:e57:: with SMTP id 84mr249378lfo.161.1600705247427; Mon, 21 Sep 2020 09:20:47 -0700 (PDT) Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com. [209.85.208.179]) by smtp.gmail.com with ESMTPSA id c7sm2662910lff.116.2020.09.21.09.20.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2020 09:20:42 -0700 (PDT) Received: by mail-lj1-f179.google.com with SMTP id b19so11597455lji.11 for ; Mon, 21 Sep 2020 09:20:42 -0700 (PDT) X-Received: by 2002:a2e:84d6:: with SMTP id q22mr149175ljh.70.1600705241845; Mon, 21 Sep 2020 09:20:41 -0700 (PDT) MIME-Version: 1.0 References: <20200623052059.1893966-1-david@fromorbit.com> <20200916155851.GA1572@quack2.suse.cz> <20200917014454.GZ12131@dread.disaster.area> <20200917064532.GI12131@dread.disaster.area> <20200921082600.GO12131@dread.disaster.area> <20200921091143.GB5862@quack2.suse.cz> In-Reply-To: <20200921091143.GB5862@quack2.suse.cz> From: Linus Torvalds Date: Mon, 21 Sep 2020 09:20:25 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: More filesystem need this fix (xfs: use MMAPLOCK around filemap_map_pages()) To: Jan Kara Cc: Dave Chinner , Hugh Dickins , Amir Goldstein , Andreas Gruenbacher , Theodore Tso , Martin Brandenburg , Mike Marshall , Damien Le Moal , Jaegeuk Kim , Qiuyang Sun , linux-xfs , linux-fsdevel , Linux MM , linux-kernel , Matthew Wilcox , "Kirill A. Shutemov" , Andrew Morton , Al Viro , nborisov@suse.de Content-Type: text/plain; charset="UTF-8" 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 Mon, Sep 21, 2020 at 2:11 AM Jan Kara wrote: > > Except that on truncate, we have to unmap these > anonymous pages in private file mappings as well... I'm actually not 100% sure we strictly would need to care. Once we've faulted in a private file mapping page, that page is "ours". That's kind of what MAP_PRIVATE means. If we haven't written to it, we do keep things coherent with the file, but that's actually not required by POSIX afaik - it's a QoI issue, and a lot of (bad) Unixes didn't do it at all. So as long as truncate _clears_ the pages it truncates, I think we'd actually be ok. The SIGBUS is supposed to happen, but that's really only relevant for the _first_ access. Once we've accessed the page, and have it mapped, the private part really means that there are no guarantees it stays coherent. In particular, obviously if we've written to a page, we've lost the association with the original file entirely. And I'm pretty sure that a private mapping is allowed to act as if it was a private copy without that association in the first place. That said, this _is_ a QoI thing, and in Linux we've generally tried quite hard to stay as coherent as possible even with private mappings. In fact, before we had real shared file mappings (in a distant past, long long ago), we allowed read-only shared mappings because we internally turned them into read-only private mappings and our private mappings were coherent. And those "fake" read-only shared mappings actually were much better than some other platforms "real" shared mappings (*cough*hpux*cough*) and actually worked with things that mixed "write()" and "mmap()" and expected coherency. Admittedly the only case I'm aware of that did that was nntpd or something like that. Exactly because a lot of Unixes were *not* coherent (either because they had actual hardware cache coherency issues, or because their VM was not set up for it). Linus