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 4A6A0C77B7C for ; Wed, 25 Jun 2025 05:26:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C87286B00AF; Wed, 25 Jun 2025 01:26:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C37826B00B0; Wed, 25 Jun 2025 01:26:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B26636B00B3; Wed, 25 Jun 2025 01:26:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 9F9AC6B00AF for ; Wed, 25 Jun 2025 01:26:15 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 3390C12306A for ; Wed, 25 Jun 2025 05:26:15 +0000 (UTC) X-FDA: 83592787110.13.006F32A Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) by imf07.hostedemail.com (Postfix) with ESMTP id 566FD40006 for ; Wed, 25 Jun 2025 05:26:13 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PlBQKT64; spf=pass (imf07.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.177 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750829173; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Q19p5suBBHA0FjneVX/xMy9RvFn5wRCXcx5IQP+EzHg=; b=fFgKWcNr8a6nZaaXJtF4gyKVi97KgyeYmXp6psJcInex+6sSJddIsNsqYMRTRXsUQPT80Y 6IZ+GJBxe5UYBTN+C+/pXek/1fub8HQxfCOHmiEg12QzuCwhimoMmTaU0PnqNFTOJCy/gT UGYo3uTwFM6YRoGOrPa8uCivge428cA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750829173; a=rsa-sha256; cv=none; b=Zq4gjSiJks26wafyNvEYLC7yeyjPDo38x44BmNbex22qmW07DC/9FseodIa0Omz5yg08z+ Fo+mpT1XPSLAMAJ1QBnza1ml1bA7WJLeG/T8GMQLq1PE5yVjUF//1GHtOqARszkNt8o27z cbRIZe+hvZKl1aTc5ZYtmzAUoM0vbXw= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PlBQKT64; spf=pass (imf07.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.177 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qt1-f177.google.com with SMTP id d75a77b69052e-4a745fc9bafso6124101cf.1 for ; Tue, 24 Jun 2025 22:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750829172; x=1751433972; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Q19p5suBBHA0FjneVX/xMy9RvFn5wRCXcx5IQP+EzHg=; b=PlBQKT6492W28zvLni5TFHyNcJKasNiFNvVfd702sFqwaZn1zmyBqAHrgCniTyG4bd lafxGvy8n5TM6J11iQOgFLlqeQQQwcc4LPgqvkgOpZF8r9eW3AD4e7UG3xl03GYI2Yr8 5BxAzJpk2TqX9Xsav4eSgOMPS8jtRYFzO6jS8RIzu7uIs8K+eaBTBcddK8m9n1JwjP/X zjuuavPNeRUantlS+xP2Q3bGBJ2j+o+aogHaVRixHf3DkJKHHpVTuC1ti5OwNxeThQ6f zN5fsI6aHTJ/GnzEbpllJArwcB0+2Bp+Xvk4HnqB0UeHwwQ9i4CM5NYZ5zbEFfPJzMBb icTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750829172; x=1751433972; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Q19p5suBBHA0FjneVX/xMy9RvFn5wRCXcx5IQP+EzHg=; b=Gau1sH8PeR6XqVQqbJNXhh5pFIYjluID/AYYgxK405L18inUpSf5F4U+cXYJPzu7wC 13NefT0vEjv/h4/rGWA6B4tXoYccuSBHt8nj3B6gd7zATp6qrlaEZEEx19Jn1yvCyAof SWRnysljlcAcy4cwJT2LalgApB3JtkiHn3dQjokgD+VQP+wS7J1/ut4LNJ4UDgrWwBz9 19qpdaaK9nmQiEjYx+YrsxZCBAviM6ICokpTddzrMaHiIrbmbJKGRo+tLygb2yV6c0HI 0pwhuu3HrLsd/LunHu8WbTLQi7wpQOcW1XfbTssw73n3Y+xn6JkDQKnHDZMw9OGudafD CbRA== X-Forwarded-Encrypted: i=1; AJvYcCW3I591WEhjNjY7GCxuSjQlyhiZKYiSC9hpJENXbN4ePydULBmtj8io6BwyjJD5RHy2e+ulALZwCg==@kvack.org X-Gm-Message-State: AOJu0Yyrl/9azfMPqzn/dDGMF80sV7zV2z/MrMIAos3PozdB+6+lwNGt Q6pfYLDI9JL9uFDnKGinyAAgKU36embZon+kHaz8tmuz8gry4S3H7WPM5pYOwmWQeJKNXU2f+RX YXOpEQDfTGHrHgYnOJm8RMRGUznz6keA= X-Gm-Gg: ASbGncsjGjtVNQN93yNf/uZ+i/28uSB5uzkQZn48PiePv3aWdJxh6NSg21A+2xoBESN +ocMnVOHKp6bBt6QSNDQNLS4z1LO2UUwAkDpxr/ny0alZwW3qP5/23qjybEMYMZSrzKeim2VonJ 9gTfVMWXoTSVRQij+tqded/AeNOGgXCIPXKhkTVwzul5U1zHcaAt/65jXi3qE= X-Google-Smtp-Source: AGHT+IEiQ+a522oTrm3IuhY8zn1XjaYyirkPysZnwpniD0hAuVUhEKLWjlac8HKEKxMvq2cb3MQTvH7foHDEY6LGtng= X-Received: by 2002:ac8:7d82:0:b0:4a3:4412:dfcd with SMTP id d75a77b69052e-4a7c12d4c65mr28227151cf.22.1750829172310; Tue, 24 Jun 2025 22:26:12 -0700 (PDT) MIME-Version: 1.0 References: <20250606233803.1421259-1-joannelkoong@gmail.com> <20250606233803.1421259-6-joannelkoong@gmail.com> <20250609171444.GL6156@frogsfrogsfrogs> In-Reply-To: From: Joanne Koong Date: Tue, 24 Jun 2025 22:26:01 -0700 X-Gm-Features: AX0GCFu34MAEFWyIgKGdiwLU6rAivs8LUjM5RQDY_BGwbOBM6uVGfN-_Vs0Q5y0 Message-ID: Subject: Re: [PATCH v1 5/8] iomap: add iomap_writeback_dirty_folio() To: Matthew Wilcox Cc: Jeff Layton , Christoph Hellwig , "Darrick J. Wong" , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 566FD40006 X-Stat-Signature: o1i39fk11nx7wbg5pfqcbyf7em8qqfyy X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1750829173-586693 X-HE-Meta: U2FsdGVkX19ycLckfaTQ/wMcKLA+sWtQ4z13HwgCqhdy1uvn48Jya2nGUuYltIXNPpEbSPO9T1iLAM+JyoN2NUVcUZ30jhQD/UqJsBfETmkPXru9zDTi9byOdw5bbFuMzxgyaIdF0qwKhUrxmR12dfhf3skz689ZNkSAApyBGDwv27HeWLjMUYTzxRBF7sG+ATjNKLeNSuTZQpkd4WtobSts5A2uKaZb9KwrPPPZMMgDhYRj62B7awYpEMucVtyV97N6l4rjd3WgvNDwuomuXCEWdtRUMbzkxPmfir1ZcatQZDUTwmdSGqf7MOd8fCmUr7+s5eb3hpIYaM/spcofLQMk48+gXJ6WSEH4bFBWbbUEDtoZ5sZOD9kMhuHOWYymYjVHfaQsUuo/SYpq9auCVrDWc4TNGXKdY17hygIPC4iuvLoseyvoEbH8DYpGmqalLpm6JcvUj5tYHsuugnkmx0AuqEOIH36K/9Ybf5IA/qeD5BbyeiEP7WbRCsD92kQgW1pGJLF3bNTOfch5AgBQkr1fQYKYqwZ0csqEqWsYQeBEUUOZ4dFQXi4gJbGhLm4dYfxTe+4+0BSyQ9BP2VlC+j9sU1XnoWcZq5DTZWMZhIJgqjprl9G7CVvmjXwKGKg0KjhRktmQsXldH6QoWLfoisN9KvqB/EEPqcLO+ulmj+cwF0RYLQBNyyfe1ftuA2ZI3yQ1aSnnWtWD1h+gJ5Cr48DPEnCtg/pD8VA/pNkeyXYSjn7RV6iA3FkRnY7oE0n9SMDlXI8MpWvJ9C+lxAe1nTxPbnP4244CXPhW6ZyveTqGSn+TCfutIexUoXa7iVrZb5lnPACNRb21US3WMN5ckM8URr8QfNtIa141Vbyrg4Bo98hFOcuDss8KWkVCQpmWvfRyRns8hElm7Y+EnrDU+1RxtIV3y23nQw5R+VDIg67QwXk8/unURHbFFIvb/4UmMq5J5Bhus/t3JZD7g/8 tv/O+xxC MGDOurU0+/MDCMA0zIbwkvVgxzjYs8XQOfmxyJ+gQI+mw486JmBiO/AtliwQURypubnzV1svTfVrdjXjkc/r9+xfaXf70G53oKeFIvCMoTxCHWBTU2aZmKvu/gsmXM6r5N0/HHOoMwSX4Jl5FEOQkPauh3B14lsuYx40FqlXRGfdINcZVhSoeoeQb440alsl4JCHeKgCrwSA64wk8Pz845BKB2es2/ClML1+L+9txEcH6zzIfKewCyQPDVSRqpOXh/GfWDrCCuL9dbZ1OsGXX6CLlDMOp+Qas9uqx34U4rSYnGf2gEahosjRqx3V7HQXkaRRcIDIAXvv/NdfcxWIw0nGJFgjjYD73zKppLPBPDX4+zMihG6Ja4RcYOajtWAkW0gY3c4QYnhjmZg9O7Y+MFt8fW0l0ycXGvwhKtoS9BUl9pQU6zyZ+h88RKmxyoV8Jw7XN6HIIHaNnps4eqJzd+nYU/A== 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 Fri, Jun 20, 2025 at 11:15=E2=80=AFAM Matthew Wilcox wrote: > > 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_r= ange; > > > > > 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 ca= re. > > > > > > > > > > I suppose it could be useful as a last-chance operation on a dirt= y 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 t= o > 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 could the filesystems that implement ->launder_folio (from what I see, there's only 4: fuse, nfs, btrfs, and orangefs) just move that logic into their .release_folio implementation? I don't see why not. In folio_unmap_invalidate(), we call: ret =3D folio_launder(mapping, folio); if (ret) return ret; if (folio->mapping !=3D mapping) return -EBUSY; if (!filemap_release_folio(folio, gfp)) return -EBUSY; If fuse, nfs, btrfs, and orangefs absolutely need to do whatever logic they're doing in .launder_folio, could they not just move it into .release_folio? > > 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()?