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.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, 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 D530AC43461 for ; Fri, 14 May 2021 11:07:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6B673613D6 for ; Fri, 14 May 2021 11:07:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6B673613D6 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 C2A1D6B0036; Fri, 14 May 2021 07:07:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C01796B006E; Fri, 14 May 2021 07:07:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC8AC6B0070; Fri, 14 May 2021 07:07:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0070.hostedemail.com [216.40.44.70]) by kanga.kvack.org (Postfix) with ESMTP id 79F5D6B0036 for ; Fri, 14 May 2021 07:07:04 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 1EEE418041638 for ; Fri, 14 May 2021 11:07:04 +0000 (UTC) X-FDA: 78139559568.31.F214EC0 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf01.hostedemail.com (Postfix) with ESMTP id 5BBE85001526 for ; Fri, 14 May 2021 11:07:02 +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 724A5AF11; Fri, 14 May 2021 11:07:02 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id AB2D71F2B4A; Fri, 14 May 2021 13:07:00 +0200 (CEST) Date: Fri, 14 May 2021 13:07:00 +0200 From: Jan Kara To: Matthew Wilcox Cc: Jan Kara , linux-fsdevel@vger.kernel.org, Christoph Hellwig , Dave Chinner , ceph-devel@vger.kernel.org, Chao Yu , Damien Le Moal , "Darrick J. Wong" , Jaegeuk Kim , Jeff Layton , Johannes Thumshirn , linux-cifs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mm@kvack.org, linux-xfs@vger.kernel.org, Miklos Szeredi , Steve French , Ted Tso Subject: Re: [PATCH 03/11] mm: Protect operations adding pages to page cache with invalidate_lock Message-ID: <20210514110700.GA27655@quack2.suse.cz> References: <20210512101639.22278-1-jack@suse.cz> <20210512134631.4053-3-jack@suse.cz> <20210513190114.GJ2734@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Authentication-Results: imf01.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf01.hostedemail.com: domain of jack@suse.cz designates 195.135.220.15 as permitted sender) smtp.mailfrom=jack@suse.cz X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 5BBE85001526 X-Stat-Signature: xth1dqtwa469i5e45pu7t1zxhup4pofx X-HE-Tag: 1620990422-127097 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 Thu 13-05-21 20:38:47, Matthew Wilcox wrote: > On Thu, May 13, 2021 at 09:01:14PM +0200, Jan Kara wrote: > > On Wed 12-05-21 15:40:21, Matthew Wilcox wrote: > > > Remind me (or, rather, add to the documentation) why we have to hold the > > > invalidate_lock during the call to readpage / readahead, and we don't just > > > hold it around the call to add_to_page_cache / add_to_page_cache_locked > > > / add_to_page_cache_lru ? I appreciate that ->readpages is still going > > > to suck, but we're down to just three implementations of ->readpages now > > > (9p, cifs & nfs). > > > > There's a comment in filemap_create_page() trying to explain this. We need > > to protect against cases like: Filesystem with 1k blocksize, file F has > > page at index 0 with uptodate buffer at 0-1k, rest not uptodate. All blocks > > underlying page are allocated. Now let read at offset 1k race with hole > > punch at offset 1k, length 1k. > > > > read() hole punch > > ... > > filemap_read() > > filemap_get_pages() > > - page found in the page cache but !Uptodate > > filemap_update_page() > > locks everything > > truncate_inode_pages_range() > > lock_page(page) > > do_invalidatepage() > > unlock_page(page) > > locks page > > filemap_read_page() > > Ah, this is the partial_start case, which means that page->mapping > is still valid. But that means that do_invalidatepage() was called > with (offset 1024, length 1024), immediately after we called > zero_user_segment(). So isn't this a bug in the fs do_invalidatepage()? > The range from 1k-2k _is_ uptodate. It's been zeroed in memory, > and if we were to run after the "free block" below, we'd get that > memory zeroed again. Well, yes, do_invalidatepage() could mark zeroed region as uptodate. But I don't think we want to rely on 'uptodate' not getting spuriously cleared (which would reopen the problem). Generally the assumption is that there's no problem clearing (or not setting) uptodate flag of a clean buffer because the fs can always provide the data again. Similarly, fs is free to refetch data into clean & uptodate page, if it thinks it's worth it. Now all these would become correctness issues. So IMHO the fragility is not worth the shorter lock hold times. That's why I went for the rule that read-IO submission is still protected by invalidate_lock to make things simple. Honza -- Jan Kara SUSE Labs, CR