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=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 0F1ACC43463 for ; Mon, 21 Sep 2020 09:11:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C14EA20773 for ; Mon, 21 Sep 2020 09:11:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726428AbgIUJLp (ORCPT ); Mon, 21 Sep 2020 05:11:45 -0400 Received: from mx2.suse.de ([195.135.220.15]:52148 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726333AbgIUJLp (ORCPT ); Mon, 21 Sep 2020 05:11:45 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 07B54AC2B; Mon, 21 Sep 2020 09:12:20 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 7415C1E12E1; Mon, 21 Sep 2020 11:11:43 +0200 (CEST) Date: Mon, 21 Sep 2020 11:11:43 +0200 From: Jan Kara To: Dave Chinner Cc: Hugh Dickins , Jan Kara , 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 , Linus Torvalds , "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: <20200921091143.GB5862@quack2.suse.cz> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200921082600.GO12131@dread.disaster.area> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 21-09-20 18:26:00, Dave Chinner wrote: > On Thu, Sep 17, 2020 at 12:47:10AM -0700, Hugh Dickins wrote: > > It's because POSIX demanded that when a file > > is truncated, the user will get SIGBUS on trying to access even the > > COWed pages beyond EOF in a MAP_PRIVATE mapping. Page lock on the > > cache page does not serialize the pages COWed from it very well. > > And there's the "why". I don't find the "page lock doesn't > serialise COW faults very well" particularly reassuring in this > case.... > > > But there's no such SIGBUS requirement in the case of hole-punching, > > and trying to unmap those pages racily instantiated just after the > > punching cursor passed, would probably do more harm than good. > > There isn't a SIGBUS requirement for fallocate operations, just a > "don't expose stale data to userspace" requirement. > > FWIW, how does a COW fault even work with file backed pages? We can > only have a single page attached to the inode address space for a given > offset, so if there's been a COW fault and a new page faulted in for > the write fault in that VMA, doesn't that imply the user data then > written to that page is never going to be written back to storage > because the COW page is not tracked by the inode address space? Correct. Private file mappings work so that on first write fault on some page offset we allocate anonymous page for that offset, copy to it current contents of the corresponding file page, and from that moment on it behaves as an anonymous page. Except that on truncate, we have to unmap these anonymous pages in private file mappings as well... Honza -- Jan Kara SUSE Labs, CR