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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 539AEC7115B for ; Fri, 20 Jun 2025 18:16:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EDCD36B0098; Fri, 20 Jun 2025 14:16:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EB55C6B00A3; Fri, 20 Jun 2025 14:16:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DCFC96B0098; Fri, 20 Jun 2025 14:16:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id CBB806B0098 for ; Fri, 20 Jun 2025 14:16:03 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 6FE45C10B2 for ; Fri, 20 Jun 2025 18:16:03 +0000 (UTC) X-FDA: 83576583006.16.50DD876 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf01.hostedemail.com (Postfix) with ESMTP id 6FFFA40016 for ; Fri, 20 Jun 2025 18:16:01 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=UB3oUedi; spf=none (imf01.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750443361; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UlFa8X9SJBeFgiRIm/NRtTllcGke3BNlF+LGXrYDlOk=; b=vylf/3GyfqjYOAcupBy2s9om1udI5kEmyQ2jYjo+lCxL6eh+ar3E56v8VxQLQPyHTtop5v TDchvqQIp/zeQ1eQNlxajzK9dQ5oNWW4wrjK0zN9dFzisGNE4b1cSu6YILfLY9o8BpgYV6 yC4FxGzemTFArhFBEEWplcvd6zqtFgI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750443361; a=rsa-sha256; cv=none; b=nMz7B8W6v2RLggSkh7tKrn6Ly5o8wRaUSWIWfqpgbeL2/0/H4nmC5ej5gbKgk0+99bbrJZ B/M/b5Zl74DJLppmEgRORX3/GllhRviofCVHepHFnTyzoSXCGjNTcriXpzn6BzPFtSTy0J 0Csa4VueFYlRWLb4iR6ztSmFQf8IhpU= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=UB3oUedi; spf=none (imf01.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none 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=UlFa8X9SJBeFgiRIm/NRtTllcGke3BNlF+LGXrYDlOk=; b=UB3oUedi3IHkRD0ogkPm/iFMhe ynOsf+94Mia5ZGyWgs95OvhaK63zn7h2fGWkCcYw7DdZYpnscuB3FlGCd1VHvX+DtbvqgXb1jwgvU mkXMU1TvqRGg/d+Ija/G8p6BXow0QtexTCZ4bXYCZnJY61TmQ73f+bMvSGrFvPpchqyb4TsViMWEo 58JOxTt57aRkRDuJraIVLOL5Wu2YD3bDHobla5k2u1NS/L/DecSj4jBD+vNYVxFDNPC2uQPe8i7Fn 50vsg97jVJQ5h8//ku2JGx1rsPVxfQomFM6wuxuWX4n0llgFYMdRTNehun/XWurgKIAjpQq/6UWFB mptk47NA==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1uSgHL-0000000DIjQ-0y4d; Fri, 20 Jun 2025 18:15:55 +0000 Date: Fri, 20 Jun 2025 19:15:55 +0100 From: Matthew Wilcox To: Jeff Layton Cc: Christoph Hellwig , "Darrick J. Wong" , Joanne Koong , miklos@szeredi.hu, brauner@kernel.org, linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, bernd.schubert@fastmail.fm, kernel-team@meta.com, linux-mm@kvack.org, linux-nfs@vger.kernel.org Subject: Re: [PATCH v1 5/8] iomap: add iomap_writeback_dirty_folio() Message-ID: References: <20250606233803.1421259-1-joannelkoong@gmail.com> <20250606233803.1421259-6-joannelkoong@gmail.com> <20250609171444.GL6156@frogsfrogsfrogs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Stat-Signature: j1jeya7aemmbn9frtoq34crkta4nt95z X-Rspam-User: X-Rspamd-Queue-Id: 6FFFA40016 X-HE-Tag: 1750443361-376031 X-HE-Meta: U2FsdGVkX18zR/BxfD+V8jfns+uBlFW6CA92nQqXD++caC/wdrUx3Co423zn3jx2qAnFb9g8mmASy2knGxF4USpq0YdJLIwcYuhJrlAyPt68b0mE+qcqZ7z4En8gYw99GaUnWOjzq1Dxi2zgEKwpnMUogBEXPhoI8y7G9MT72YMi/fthE3jvVUfFX0huaLind/UPEjeMfH4rRLog/WKSyuZJJPgiDKk+MEozVIc2U3fDfu9cis48UMCip0infspU6+chv1DVc4dMkqXGg3J78fjhifOkDq2Ol64L5NshFB+XMkXJ6VLk+VCTKKW/wksXz2s8CkzO3pNsubik2Ik8dNzSW+Cou7Ae30Ir+7bS1qzpYIF0Co6hmob/J4t35Kjct+mgvsO94V5txjuE9OeK1/zmL1wp3PHojMvzC11XRibTYsOGSDFI4ZhuwXo+pHfPH0LDLvsehCu+qSg8iS3eqExXnMO/O4+E068QFPHKsPZJmSl3yWhlStBjHIE0ss1E7W53H7A6TqwvocKTXRC78XjXlAfK0aW7lfpZJqKY11bnFAy5h9YNyoO/FbrfV0QF3HS88WBjlZu06Z+MEBP4q1F7B6TX5Z7idDIBev7OkIuzNS06rone6wVt1oGjzHEyxBng3ZLF4oTk646xmVQx+7hvtzjDeDBj22GIMiapXC50R070huGQzToREMnIXPKTSJzgOGz9Nl4pzWgLijtIRgbWrKDnRZWJoXdmjKbnYgjsc7K8cVL76wUAr3lKfUg9JCivQxoIz4V4Lalzkk2+uHHnpY7IthRkZYyknAWPcSiGOoljcU0lZHjQo5V/i+TJpL+DUeMv8Bs26K849rLraemauq8mmdb6vLJtMKQChdSyJsj2B8rEmKpWyqx0fUCpH7x76wj2y5XD2BlMd+lzJyDNgMJyVfJOX8TLhH0RuSwID0JYZUvlRmQV23HEWat8d/dKyzSqjMpOA/WL5oC wAXLXnmQ SYBLZM7Mn74EkEh8RRGVbSvrVFyV81VCgJaM7Wsb5hGqnvdgD9yoYc8Hv7pNEGr4Fo54RdcjppqHbyFr4p2+DnWt8u6XWVhjIZNeuDcj1CgQk4uVEF0VeW4++7uCnZLZAAdLD3raKH28d7a1ARmfekbDoCyu0vphdnSdANAd0ENs3Zevyugy5ycspLeONS5es4kHCCIWJip8sd3wDbRwqjo1SChADloa3eqNCaC+SlKZh6pyYyHBnmrSvpgqqg0SUHeuhvocGDkm1gogeuPgRXdmE7Q== 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: List-Subscribe: List-Unsubscribe: On Wed, Jun 18, 2025 at 08:17:03AM -0400, Jeff Layton wrote: > On Wed, 2025-06-11 at 05:34 +0100, Matthew Wilcox wrote: > > On Mon, Jun 09, 2025 at 08:59:53PM -0700, Christoph Hellwig wrote: > > > On Mon, Jun 09, 2025 at 10:14:44AM -0700, Darrick J. Wong wrote: > > > > > Where "folio laundering" means calling ->launder_folio, right? > > > > > > > > What does fuse use folio laundering for, anyway? It looks to me like > > > > the primary users are invalidate_inode_pages*. Either the caller cares > > > > about flushing dirty data and has called filemap_write_and_wait_range; > > > > or it doesn't and wants to tear down the pagecache ahead of some other > > > > operation that's going to change the file contents and doesn't care. > > > > > > > > I suppose it could be useful as a last-chance operation on a dirty folio > > > > that was dirtied after a filemap_write_and_wait_range but before > > > > invalidate_inode_pages*? Though for xfs we just return EBUSY and let > > > > the caller try again (or not). Is there a subtlety to fuse here that I > > > > don't know about? > > > > > > My memory might be betraying me, but I think willy once launched an > > > attempt to see if we can kill launder_folio. Adding him, and the > > > mm and nfs lists to check if I have a point :) > > > > I ... got distracted with everything else. > > > > Looking at the original addition of ->launder_page (e3db7691e9f3), I > > don't understand why we need it. invalidate_inode_pages2() isn't > > supposed to invalidate dirty pages, so I don't understand why nfs > > found it necessary to do writeback from ->releasepage() instead > > of just returning false like iomap does. > > > > There's now a new question of what the hell btrfs is up to with > > ->launder_folio, which they just added recently. > > IIRC... > > The problem was a race where a task could could dirty a page in a > mmap'ed file after it had been written back but before it was unmapped > from the pagecache. > > Bear in mind that the NFS client may need write back and then > invalidate the pagecache for a file that is still in use if it > discovers that the inode's attributes have changed on the server. > > Trond's solution was to write the page out while holding the page lock > in this situation. I think we'd all welcome a way to avoid this race > that didn't require launder_folio(). I think the problem is that we've left it up to the filesystem to handle "what do we do if we've dirtied a page^W folio between, say, calling filemap_write_and_wait_range() and calling filemap_release_folio()". Just to make sure we're all on the same page here, this is the sample path I'm looking at: __iomap_dio_rw kiocb_invalidate_pages filemap_invalidate_pages filemap_write_and_wait_range invalidate_inode_pages2_range unmap_mapping_pages folio_lock folio_wait_writeback folio_unmap_invalidate unmap_mapping_folio folio_launder filemap_release_folio if (folio_test_dirty(folio)) return -EBUSY; So some filesystems opt to write back the folio which has been dirtied (by implementing ->launder_folio) and others opt to fail (and fall back to buffered I/O when the user has requested direct I/O). iomap filesystems all just "return false" for dirty folios, so it's clearly an acceptable outcome as far as xfstests go. The question is whether this is acceptable for all the filesystem which implement ->launder_folio today. Because we could just move the folio_test_dirty() to after the folio_lock() and remove all the testing of folio dirtiness from individual filesystems. Or have I missed something and picked the wrong sample path for analysing why we do/don't need to writeback folios in invalidate_inode_pages2_range()?