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 7FDC4C7115C for ; Wed, 25 Jun 2025 16:44:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D5EC86B00B6; Wed, 25 Jun 2025 12:44:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D0F9B6B00BA; Wed, 25 Jun 2025 12:44:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD75B6B00C9; Wed, 25 Jun 2025 12:44:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A62946B00B6 for ; Wed, 25 Jun 2025 12:44:45 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 5FDBF104215 for ; Wed, 25 Jun 2025 16:44:45 +0000 (UTC) X-FDA: 83594496930.25.87C05D0 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf28.hostedemail.com (Postfix) with ESMTP id 739CFC0010 for ; Wed, 25 Jun 2025 16:44:43 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WLIxr53j; spf=pass (imf28.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.176 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=1750869883; 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=ARfY5zPdbMWR4dmRIiBvFi5s9kvzkJcvkpzDRoJBEK0=; b=zLOQrIysuHZFcz1ucmgiB8U+fwkdkuvUigNXsbqZVhUnpNY38bihgx3JBcCCtriJ82VLyR JdxWH/58WFer5TLpkaf7GfyMvKTSAj6MoL50/MqZpkaGuDnQymwWG0BIGH2RJXQ8VeXbuH DfaQGsJN+WuIjvTi2oan5aXQ479ico4= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WLIxr53j; spf=pass (imf28.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.176 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=1750869883; a=rsa-sha256; cv=none; b=HlPt7F4+CZPhOwKLvD+DtQk5azEDcTHoXvCs5Ld4QHQCnPl8ww+szSF8WZ1zzOogYF/wFv 1IXKyi4Jp1BJAEuDU6uf5UMwDWWQy2pQvbI3a2hM2dPQNl5+wEelZ0Nzs0yHKYhRnD4q1L 31EAybKW5cBfjjGe/ZDyEREx810aST4= Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-4a4323fe8caso985981cf.2 for ; Wed, 25 Jun 2025 09:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750869882; x=1751474682; 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=ARfY5zPdbMWR4dmRIiBvFi5s9kvzkJcvkpzDRoJBEK0=; b=WLIxr53j1WRmIMWOfoPwzdWVMKhJ/mSkjahLx4K61+FWm118sGJjkTR76NnhAlfJN8 ZYps43NOq736DO3p7Uh9tszPFzpUtwIgP/tbbml0qK4CUHGyPtHyl2h+ooIco+wzqsmu thHBo9O8u1ky2AlzWDRiGslWxi17XY/h7zEiyfIk5bM50bE0trowSJnopgjVmrN7W2it z198AmhjTMi6Uj7LIIrlUuDLc/s46G2rIH6saEnGzNDFKxd4gLxI8uWcaBOo+8Ds87R+ SakkSESC0Z0rLawzHXGqSRClkkIlCGqM3tvXbe726nD+x4eSIkJoVeLSX5RTIB65lRKJ gdnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750869882; x=1751474682; 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=ARfY5zPdbMWR4dmRIiBvFi5s9kvzkJcvkpzDRoJBEK0=; b=DKJbnT4mcJog2E3gZhcK49zYosVBFvfn3+SIlT455qzKIc4tPeXFXoq8uAxe/z+jT/ swLZW64SvwrpDJetrwmh4KPO78GNMEHY1dZum3ftOZCaGzJZTJohM1p2K6KEpspd0I8c HO9vTowMu/YZVpE+9wrMYLpACNwuSoVe1pX5ZrV28gakXoi8NA18NnZWeaDusQQvNPH9 xNmXj7SCXNAp2P5TEvjPa+TryErRr7GC/toHouzYxxU9zjwRU9/T5Fe47S1bQpBlRr/7 GRrOmMMOnFUP1VKdkQdgTgmOIbTWUojqLNmZ3lAKIDcE5JDC1aI9YnUIPFruH5VnW+1u VuHQ== X-Forwarded-Encrypted: i=1; AJvYcCUIP9uEzSxIOhWs5mYkW0FqY7gRQ8vsqP3YLM+dFlOQimNqO40+Lx9Cep9+5k5RKajaXNZg9sjlRw==@kvack.org X-Gm-Message-State: AOJu0YxGT/cIqwYsqaZtMQJeBN3ivammKlARSUCKYuKWi/kzKk5ZInco BeM0SPlR4HgTGgd3PvDsWgMie/tUHvtJTXWqNmVUNeYj77KgzTE5CR74enyj1zqBl+4/yQNCmkZ zJR1uC8PvJhYUTLNToMrGH5RV513I1Ac= X-Gm-Gg: ASbGnctNM7KDD8Uu8fuNrjDRh6IvIC6UDCf4vWhquV+UzuP/WQ4YC0XChctR0+/hyus h0I+SrVV7iX/w3RtcaOjsVSqOJ+N9VNfVzPu85IyPoWdxnl6vBdvt+iccJTLRmKcSTeKHzT1NVm JYtSLyJsDBbES6/QteFEnl4zdsH6EHkto4FKzBA4ZiUZpRHtUCJgg0Jw4lhLGMzh4sd5wYPA== X-Google-Smtp-Source: AGHT+IEt1TZjaS3R5h67itrFgkyntPJUD/CIMKEaOvyxiUhcZBapd1BPlkAKLlT0ccLQcSXu/Z+jtrxAl9OMK4WdDic= X-Received: by 2002:ac8:57c1:0:b0:49a:8542:b496 with SMTP id d75a77b69052e-4a7c07d54bcmr54002001cf.25.1750869882315; Wed, 25 Jun 2025 09:44:42 -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: Wed, 25 Jun 2025 09:44:31 -0700 X-Gm-Features: AX0GCFsfnY2NRe1Yl1NZniTcFCNWF9j0FX7uW-sdQQQn_7h6m7fdnADoW5ryf3M Message-ID: Subject: Re: [PATCH v1 5/8] iomap: add iomap_writeback_dirty_folio() To: Christoph Hellwig Cc: Matthew Wilcox , Jeff Layton , "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, linux-btrfs@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam11 X-Rspam-User: X-Rspamd-Queue-Id: 739CFC0010 X-Stat-Signature: 96t8k3sjd7rift77a5ggimajttumft99 X-HE-Tag: 1750869883-602721 X-HE-Meta: U2FsdGVkX1+bze2EdFnAIydtu+HCI2WFfRYfcu1ixTfHLdl7B9+hyUcuwDTzaBxXi+DU9Jzs1BsC8nNadtWMqH6kxTH7zh5bO1D6LtTrl7ItQWnLD9vTFL7n3/UkxBp4JZ1SF8JvZOqP9/JYAeSaf18J4wSOOchfpB8E2qI/0Un5XaM+I2iOf51wh4GQD/QwJWaVrUUhzLoYxzBRkCArskCee3eLcx42E3xRIerlWjTmCElsShK8SLUxNUM1rtOeAo3U3RcfX4IV7T+47KRYBnI8U0+6KC1ccZS3I/4G1nSJtsaygKWEt9lOSjW8i0tT1r28pnBaJC3ETX9QmI9BqYfuPlva/cNMPK2iMkV7kkusp9yYm9f4FM/oUBFdAYraq6dmLCVKtyMUXG/9Cy7JBZUU0JqrvgDH+c2xJ/bTNycRyBzSaYQB2NK7qQ0rVN89W4/+VM3fj8/oP3dLl7bTMhCWMQQxkeMfhMpJXXY9TVRdNfWPpFCeIu7owLJMUgahD6mJLCalr8lZU6VV1Px1TG2xaO5y0uhY9qQzl/ZCC/tRMFAKvyOMXlWQshOvmP5GWtEm+70Fj54n4sKaTxpJuutwHIuvXYSr7ZZ3h9i2S/We63EpCZEqUtzQaGrf2Z13JuFYAVhq4SWv8XS15j+E1JJ+JmPq6I7CIi82lje/4hjI/CMP8dzpNWi1OqUKtNBjRVOSXp6zuTcGIiA1NeEA/Y33XMThCxr0o3lqh9drU4nHQhxTzb1O4e+bH0D3uDDnAmn7ZVALmdfOLXUgIaoFkvk/YyzK8gNDg7LvS0s7FdyZ4quNREwupkbQvXrOspxxGEAP0nWYmwgBTYF+dL06g7mle4lD/m3uz3+o0bW0EFqpfxU30b7LwEQbYK0bpMAJbxkZnrY9YgWFuWdz6slVoxzwxB+XjnPtSuEAJyY3zuBaaP7J5vbzhfb4AoX6pOFgfl6t2jeVHk7hc2bEUdZ 4LHbfJiz DCDHR06B9wZISCAcn2it2YhsOU9DvwxMeoCbI/qgpEgYI7MWpFIck8AIFkgiS72nyZ9j05YVR9TinKMxv0AKjEQ/kei6fJ1GS77LPIwTwuBx4+BE5ZcNLVfIXyG67SoFCzdzXEQqOmfAiofcpyCGAz7tccWgPC6gkCv2MWZjxI9KAhwdVIrCBCRgxDC9CgiozcT4vzbg0gOi5F2e6Bu9CrSmTfHj2h/jk2oOGCqQLarTa4juGlm3lPgl+uqtpeozB8/R0jgq+Mntoxd/NNfXHMpo1rrwQtSpbehFKdktFhtdhtJs9LZqcRdzH3xd+fyExtMIEU86KxHFv6E6kOTJ1XJtgfZ857KbuncQwCykDXwfMiHQoW7Y/q7X4CS5sbz+KFaLTQdIBHjlMx94SREQjbZxYo2cxpkqeT3ov4K9wrzOxmrY= 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 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 move th= e > > > folio_test_dirty() to after the folio_lock() and remove all the testi= ng > > > 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 basically > doesn't matter. You'd still need the write back a single locked folio > interface, which adds API surface, and because it only writes a single > 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. 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 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.