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 99A02C43464 for ; Mon, 21 Sep 2020 09:11:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F2E22214F1 for ; Mon, 21 Sep 2020 09:11:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F2E22214F1 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 352A3900049; Mon, 21 Sep 2020 05:11:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 30346900046; Mon, 21 Sep 2020 05:11:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 21843900049; Mon, 21 Sep 2020 05:11:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0157.hostedemail.com [216.40.44.157]) by kanga.kvack.org (Postfix) with ESMTP id 0D259900046 for ; Mon, 21 Sep 2020 05:11:46 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id BEF9A181AEF1A for ; Mon, 21 Sep 2020 09:11:45 +0000 (UTC) X-FDA: 77286500970.27.ink91_2511c6e27143 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id A12C43D668 for ; Mon, 21 Sep 2020 09:11:45 +0000 (UTC) X-HE-Tag: ink91_2511c6e27143 X-Filterd-Recvd-Size: 3849 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Mon, 21 Sep 2020 09:11:45 +0000 (UTC) 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) 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 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