Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp2986930pxk; Mon, 21 Sep 2020 02:15:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJypTNb75/mcFF6TfjOjgM9BaMgOUmM2liF1diyljPAUvDQe4lF5MipD/VEUa/w+4/VY5i2W X-Received: by 2002:a17:906:7fcc:: with SMTP id r12mr50019887ejs.360.1600679736886; Mon, 21 Sep 2020 02:15:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600679736; cv=none; d=google.com; s=arc-20160816; b=yFKSlreRKb/+tV9h/HcVDppUY6sasXS/u1+u4G+eav/1RyNYhXLHSUgV1htAquL5P8 OBA1VQXkCGGECVa24MNJ0rFh+fXkT3ai8peNjuy93CFW2ud/mhHQW7z7RLiRDUTPBrFa wbAVGhjrLtMLTNf9V9XN4Ax3pW0kClXv2OP6MFbUneHNbQSEgaJ41efdF1yU1rVxj1uJ IZei90gNt8bm+gKh714vFH1ypsjX4xkm/QhuEGeO72P3gygNEooOzytK4Ddz7W7nyTd4 okOyLeS5zyuHPeRUw2SuAu7lnaNJHAvZs6JFwKf+eZNZx7ZdorwqiCeLyeGY+nJBvnbg svlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=yc8UcjMyR+KyhV0JsUBbTLOMc5wLztc0b2+C6iSfRAI=; b=pzIHGlHwggZ/rQXHa36QVA+sdFPCtqT7uStrVRMa1mo+2Bxk9gHF+E6eSFdQLvl1dG 9LgallC3QzpOMrMuPA4YTRUwpkXAs1DzJJ4QcrCCeyy5Po7DqQ3+uC5hJ8BOQY6j71l/ k7WjFLniPqp7NEhTffrTff+nfV170gWQW00rS0NGFxZWVchNPc8M79g4uHh5iXpZxIN6 zJXLtNHGOqWea3uSlEpwNPTE1iKnzAinB4/2zovf0Bp0geXV+A4U30Xm7nTQDGpr7S/O xnbFPj1xFvEDbWtU1Nk95TsKOos0s5/Qgk5R2Hxfyc35wX+mScjazDYIALCIuMcgh+7x UM7g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c8si7862530ejp.43.2020.09.21.02.15.13; Mon, 21 Sep 2020 02:15:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726479AbgIUJLp (ORCPT + 99 others); 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