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 6373BC4363D for ; Mon, 21 Sep 2020 18:00:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CE1E420BED for ; Mon, 21 Sep 2020 18:00:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="cn1Zppxw" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727931AbgIUSAA (ORCPT ); Mon, 21 Sep 2020 14:00:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45836 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726436AbgIUSAA (ORCPT ); Mon, 21 Sep 2020 14:00:00 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 04CE5C061755; Mon, 21 Sep 2020 10:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=EYalxu71FXkhieQDqm3YOx3Lopqwd5EDbAcvH4qgOhs=; b=cn1ZppxwRY81oXiNm0vRnLyCFs Xl5xURoMhBnqr2NAEHsKV+Yt0xLaL5tT+bhVHEInqaezHoHp5ln5P0NE4NbQUyQ/JA7hTmee5MQSv Gx4g48bXYVJSDGVL4YSAf+VQIzMvlFAv+o8q5hLXRp9CBiHnAy1AqXzqyUH3ZR65gj3A2LQVw0lqH Qz1GsKVlFrTrf5GNRFnMVYe2c2MMzmOpjxQ4I5XffgCWR2Hb9GG0Zo+JWhEMO7d11kCVug0WBiHsk uzjFDYrt1qxk0nMox3iIjPWlwC0J4P5ST6FeF54rmXxKGGMdxudBsLGdsbKrQKVjihsLADUoJVGzn QR0vNZKg==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kKQ6J-0007Cd-IL; Mon, 21 Sep 2020 17:59:43 +0000 Date: Mon, 21 Sep 2020 18:59:43 +0100 From: Matthew Wilcox To: Linus Torvalds Cc: Jan Kara , 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 , "Kirill A. Shutemov" , Andrew Morton , Al Viro , nborisov@suse.de Subject: Re: More filesystem need this fix (xfs: use MMAPLOCK around filemap_map_pages()) Message-ID: <20200921175943.GW32101@casper.infradead.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 21, 2020 at 09:20:25AM -0700, Linus Torvalds wrote: > 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. We don't even need to do that ... "If the size of the mapped file changes after the call to mmap() as a result of some other operation on the mapped file, the effect of references to portions of the mapped region that correspond to added or removed portions of the file is unspecified." https://pubs.opengroup.org/onlinepubs/9699919799/functions/mmap.html As you say, there's a QoI here, and POSIX permits some shockingly bad and useless implementations.