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=-10.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 8EF6BC433E6 for ; Mon, 21 Dec 2020 15:17:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 55B9C22BEA for ; Mon, 21 Dec 2020 15:17:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725962AbgLUPRU (ORCPT ); Mon, 21 Dec 2020 10:17:20 -0500 Received: from casper.infradead.org ([90.155.50.34]:42962 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725826AbgLUPRU (ORCPT ); Mon, 21 Dec 2020 10:17:20 -0500 X-Greylist: delayed 1078 seconds by postgrey-1.27 at vger.kernel.org; Mon, 21 Dec 2020 10:17:19 EST 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=BLzw6+zjh2rdSHdmNGpYDXRXsmUwYCvcQt9chPzOa7U=; b=t79vddqgv5Z/JEAuj+pP7dMB+z rFsHF/unk8uEwlNNGR6rOV/bmVbEQ3JaisuqyzR8cplsVbCj7+le3vcpa2EKrQ16CEiUqHCiH5rA9 xMaue/iFO4x35e5Rq4MiHWFAWF4grGL83O94mgcB6iCv+di+S/mlmKgBaUXFqICXhZF6G5hDrU5H7 o7tUTpF7K7dEbZIX3ut0PuNEpqzuqnXkDzIKW7xB3ph2xdfdSxIW6ha5FvFBM/1bZYtFPyCYQCkHq DBBGITOliGDA2SaTdAefd8iUY0s8VKP9kVDfLezJWbdoQ/K1AVgVXECaPD/pyl0CMi7d2ZasDQ+7Q VsAvXPJQ==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1krMdv-0002jS-RL; Mon, 21 Dec 2020 14:58:35 +0000 Date: Mon, 21 Dec 2020 14:58:35 +0000 From: Matthew Wilcox To: Jan Kara Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, Jan Kara , Theodore Ts'o , Andreas Dilger Subject: Re: set_page_dirty vs truncate Message-ID: <20201221145835.GB874@casper.infradead.org> References: <20201218160531.GL15600@casper.infradead.org> <20201218220316.GO15600@casper.infradead.org> <20201221141257.GC13601@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201221141257.GC13601@quack2.suse.cz> Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, Dec 21, 2020 at 03:12:57PM +0100, Jan Kara wrote: > But overall even with GUP woes fixed up, set_page_dirty() called by a PUP > user could still see already truncated page. So it has to deal with it. Thanks! That was really helpful. We have a number of currently-buggy filesystems which assume they can do inode = page->mapping->host without checking that page->mapping is not NULL. Anyway, since I'm changing the set_page_dirty signature for folios, this feels like the right time to pass in the page's mapping. __set_page_dirty() rechecks the mapping under the i_pages lock, so we won't do anything inappropriate if the page has been truncated. You can find the whole thing at https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/heads/folio but the important bit is: - /* Set a page dirty. Return true if this dirtied it */ - int (*set_page_dirty)(struct page *page); + /* Set a folio dirty. Return true if this dirtied it */ + bool (*set_page_dirty)(struct address_space *, struct folio *); I'm kind of tempted to rename it to ->dirty_folio(), but I'm also fine with leaving it this way.