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 B0335C83F03 for ; Wed, 2 Jul 2025 21:36:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1C2686B00CA; Wed, 2 Jul 2025 17:36:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 14C076B00CB; Wed, 2 Jul 2025 17:36:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 089DB6B00CD; Wed, 2 Jul 2025 17:36:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id EC6386B00CA for ; Wed, 2 Jul 2025 17:36:50 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B9E74140477 for ; Wed, 2 Jul 2025 21:36:50 +0000 (UTC) X-FDA: 83620634580.28.0BCA509 Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf18.hostedemail.com (Postfix) with ESMTP id D624D1C0007 for ; Wed, 2 Jul 2025 21:36:48 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DyRbZ2eO; spf=pass (imf18.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.169 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=1751492208; 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=Plb9BF29bvzrheIEVugeqNq8ipYFwItYmCmavrVWnAg=; b=dKF38PmYnJsaKo+WnNYaTcs2Q9LF3Z8bQoNFZwg9+7Or/aGED7qCbIGYeQBiHJUaZrugVh +fRO/h/G7JlozHcSB4SlcSZwlYgmOgRGcqlGX/Bbzizh0LRkKJiFJlAgoimjgp57MJPfSS s3xmttH6OAjSC42iPq75CTqfuYIzU7U= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DyRbZ2eO; spf=pass (imf18.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751492208; a=rsa-sha256; cv=none; b=UvF5jd+lJC8IuvNHX/YT1xlbo+IMWHU/a3iEKbxpAspxOgr+hFCuXc4I/hAwSG1iWBHQ2Y vb0xqSP1zVX926o7aYMveCAHmqMP8cnFVXUfBWEhxNUwSXmVxVU2K6dBtG7UmBS2hCnoi/ Cyrf4+6VsQZZbcp36Pq0swjdgMkBdrQ= Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-4a58f79d6e9so95092871cf.2 for ; Wed, 02 Jul 2025 14:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751492208; x=1752097008; 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=Plb9BF29bvzrheIEVugeqNq8ipYFwItYmCmavrVWnAg=; b=DyRbZ2eOQ8XTmrByCH6PBJgVdar37PDsLUjLqjAionSTnDWDaSEUUkdc8WvT6cGb54 LNpnDSMgClcIwrUErgTMVYq21Gfep4RHGD5T8GMeRaVghijEu7A5hAA7cZq1uXimyk+F HoOyXfweRbj/dzk1SkNWyYk1qZ8HWEf4OvMPIUd8uTCP2JIeFfP/ZK5/llVan7nb7nnU wez2MONixMKkFN7C9Jj0QPZGekPIl6m035R7/kApspjvGNo5YDQL12bm2p4R7tdTP2wF GxgvIWL2+DTzLjwisNRtl5fSp6LjTa1BU+HGH2gZ17qzA6RrT0eV3gGpRvSdaRgwb5X/ gQAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751492208; x=1752097008; 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=Plb9BF29bvzrheIEVugeqNq8ipYFwItYmCmavrVWnAg=; b=THaylV/kSMSoTvQAfUeB4eRvRgyky91NS94h9Gn6HmHWL7unvovLx2xCgzqcHFXY45 AYUjYr5QfoeJqMOMRDTRx28rf/J6UAn0M3Ri7F8LnCno+lu6+n9YgHClaGyULADt/nr/ bGr7LJeUpV+h31SYJ38OvnMZRK+cqmxJbp5EaC7AefG85z+p3PaxtR5ZrBAvUzfVXrRB eNaVZ0QC3zFcCfSOfyfh4BlrqFGwTpDuhMiOjm/NziWcBHf1mGEw/jxnRIrHJzL18qXt qgALSrvzvmOrT9HCa6aoMz9XlpO/f0xNjozLCizA/1MFj9D9IEikCUPPbnaHbp5kf/0E zS6g== X-Forwarded-Encrypted: i=1; AJvYcCVizbeK6LBEbqEhjZ8E/SYL8MBddhEN67R+spu7wLJIjZDqt2gbn5CdCkgRhjxLlpNQhQXA2JpyuQ==@kvack.org X-Gm-Message-State: AOJu0YxjWNxk5MlNML+fA0CZbNdCbcwpRnQC0seWFoRESeyzQ4Y9kouh zElOb5MXzUuZ+OmPJBwHduR1gex569MAZQ7Zp4Ugnal7Dq2eZX+V3K0w2pS9KCPBy8dLGdwmZ2x xclGMjRhtPO+Brn4gj52fgLAb4ivQUdI= X-Gm-Gg: ASbGncuzvA1bsEVgOBsIChqOlkO6E0yvkHt9jFG+NTNbc55dFTqW3VpleycvQZn35W4 pkW54f+L5zXGTCEJN+ISwhUeyNObBuah/0YDVDJsmXyYafqZrtqEGx6Zunsu/Cclz34WpMahANW 6fDWgvMRgSs7I/3ie0fglOGTZn0pWc62OlElHDZ20ktjq7OKkKpq8q8xVRtot/VUmrV5KtvQ== X-Google-Smtp-Source: AGHT+IGoQva0z93Hsr6cBS/xQ/Id5Yqj3FdAJiwkeHWw3E4i6JnSDSeEzC3aoZIo+aKKEQD7P9uX+qd4H+iuIJAjkfw= X-Received: by 2002:ac8:5794:0:b0:4a6:b603:c37e with SMTP id d75a77b69052e-4a987bd7e34mr16338791cf.2.1751492207835; Wed, 02 Jul 2025 14:36:47 -0700 (PDT) MIME-Version: 1.0 References: <20250606233803.1421259-6-joannelkoong@gmail.com> <20250609171444.GL6156@frogsfrogsfrogs> <20250701054101.GE10035@frogsfrogsfrogs> In-Reply-To: <20250701054101.GE10035@frogsfrogsfrogs> From: Joanne Koong Date: Wed, 2 Jul 2025 14:36:37 -0700 X-Gm-Features: Ac12FXzkj0LAvJbdt1VVEKID79S4TlNmpTpl9CLd_GKa4oYm2ZgQZsYKKutZU60 Message-ID: Subject: Re: [PATCH v1 5/8] iomap: add iomap_writeback_dirty_folio() To: "Darrick J. Wong" Cc: Christoph Hellwig , Matthew Wilcox , Jeff Layton , 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, linux-btrfs@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 5szqgus3n96wowtnf8mw86uf9yk19n4t X-Rspamd-Queue-Id: D624D1C0007 X-Rspamd-Server: rspam11 X-Rspam-User: X-HE-Tag: 1751492208-790319 X-HE-Meta: U2FsdGVkX19K/aWqTwt2Bw6H9/jy9XN98l4OqyAM++gI2BHN3BMToMgF9OFnmoovTnwOmP2RWJfipOQcV8cD8nzH6E7INFG8wB5b1gJdL7Yu7zUYQl1d3sGKr/DJAHpE3DBG+51b5XAjknwLEXA8glyRjLJ5FCfawJ/DC60ncFKOrxKfHSnMbBtXwWW5+Of4WsVUzCXdOVgJOWekPDaQqArtUEG0Esjc383LR+zB2XH0A1Xz9OPU/yntgRMSJsfKF83yf1vKLDMmQ1gI8vCRGBiJY2lT1rDemXA4lwEJ17qgAmN58WDkvq2TlbXJKbgSYV1xbgZlog47dhUsCYyM0hglHBU8cKuPbgzXxON0LHc48eotsE0GwK23MrfaZs1sHEGiMvYhylbFYRjDNWVLB3FT5Rf6//XLbdegJWoxSYMbaui+0uCwhcmDSFmzlHHQvj4fO+ODTFTc9yw+fFmMevTFruPU27ZfQWoROL0jzRYorqGoo/lzG5yVc6KW6h4hMsNoFbQdBqkKr8b5dnnQKIsizGcAstzl0lYYKoj7XEJnMNdhufh0nJMAvWbm8W08CvVhqqcCOS92FdMvINDU2P/sM0iTAjczu1DG+unFDxsewL9yA8eGRwFYHjOK8tVakFAKf/tvE5bpDFeB1uG/ML7boNbSxKVJmO8IA+Iyixym4YZ1r/4fuXl+8DvY8z93zkv2I081M+lFt5o7rNYRBkepPOjmKthcxea1+fN7MiiBIVbt0WU6+aPcS7EC4rUp1DBxiHWh/Xg9P+hDlAXVfk+PX22dwu7hQ/1iwDtgt45La6ZVZSyYwkqanQupQez90OdY61leuiieYTzGXlDs+TUI+/wGzXXguxWnRRnaWyrr6eMxRKWbDPG+fwXeHOHtuS8iTdZgcTlTV2D2Gow+vw/aXmb//pFfa0Z0I7gOkJnn+Drl9lTRnfrsK/KyWKynBUpzFbkaDm6LYeYzguO eIymJ2ns W2E5ifbIpAJcCitq8cgjQUDTTIUepq9YtVJBn6lya6xCdHmfGemkgvkTU8sf76S6HpfZrsQZl1zdKGImw7UYahlPyUTtAggzQvWyBsWuRNw1nP+7woIXAPwCWlKPiHzo5M1U4aWBItL0ENiQjq+uGPWANztpAivcRwNDhFU7FLTSYZ2wxiqWjhdBpfJNz+FuoV2q8eFZ6iw2wj9LhrnMIRjl3JesEEL9niU+E34qjy7CKCWi/YLEzzdSH6/4iUYEKHeNF1wvIvTLk0Ke67nxGKzy4aWrxRLz1vXykt+4r8DKrEmVqRAwnSQDhbPwFXH6QKL8DFTr2CzxVHARaN5WE4XmJBfdnxBzXcB4ZmjM+m8zsD4oNfmbizuUOskpvh/000dL+6Pd8gp2RmIp513zIyhQF4UBYzCJNP28syo9lLZyt3/f2/Qxo3THkXowU1VM0RezByuNVukjJyxpz8TJgi0kZ+uQ96ENUXivMVgBhpZc3+Ik= 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 Mon, Jun 30, 2025 at 10:41=E2=80=AFPM Darrick J. Wong wrote: > > On Wed, Jun 25, 2025 at 09:44:31AM -0700, Joanne Koong wrote: > > On Tue, Jun 24, 2025 at 11:26=E2=80=AFPM Christoph Hellwig wrote: > > > > > > On Tue, Jun 24, 2025 at 10:26:01PM -0700, Joanne Koong wrote: > > > > > The question is whether this is acceptable for all the filesystem > > > > > which implement ->launder_folio today. Because we could just mov= e the > > > > > folio_test_dirty() to after the folio_lock() and remove all the t= esting > > > > > 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: > > > > > > Without even looking into the details from the iomap POV that basical= ly > > > doesn't matter. You'd still need the write back a single locked foli= o > > > interface, which adds API surface, and because it only writes a singl= e > > > folio at a time is rather inefficient. Not a deal breaker because > > > the current version look ok, but it would still be preferable to not > > > have an extra magic interface for it. > > > > > > > Yes but as I understand it, the focus right now is on getting rid of > > ->launder_folio as an API. The iomap pov imo is a separate issue with > > determining whether fuse in particular needs to write back the dirty > > page before releasing or should just fail. > > This might not help for Joanne's case, but so far the lack of a > launder_folio in my fuse+iomap prototype hasn't hindered it at all. > From what I can tell it's ok to bounce EBUSY back to dio callers... > > > btrfs uses ->launder_folio() to free some previously allocated > > reservation (added in commit 872617a "btrfs: implement launder_folio > > for clearing dirty page reserve") so at the very least, that logic > > would need to be moved to .release_folio() (if that suffices? Adding > > the btrfs group to cc). It's still vague to me whether > > fuse/nfs/orangefs need to write back the dirty page, but it seems fine > > ...but only because a retry will initiate another writeback so > eventually we can make some forward progress. But it helps a lot that > fuse+iomap is handing the entire IO stack over to iomap. > > > to me not to - as I understand it, the worst that can happen (and > > please correct me if I'm wrong here, Matthew) from just failing it > > with -EBUSY is that the folio lingers longer in the page cache until > > it eventually gets written back and cleared out, and that only happens > > if the file is mapped and written to in that window between > > filemap_write_and_wait_range() and unmap_mapping_folio(). afaics, if > > fuse/nfs/orangefs do need to write back the dirty folio instead of > > failing w/ -EBUSY, they could just do that logic in .release_folio. > > What do you do in ->release_folio if writeback fails? Redirty it and > return false? Yeah, I was thinking we just redirty it and return false. I don't think that leads to any deviation from existing behavior (eg in folio_unmap_invalidate(), a failed writeback will return -EBUSY regardless of whether the writeback attempt happens from ->launder_folio() or ->release_folio()). > > --D