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 3A3D8C83F03 for ; Wed, 2 Jul 2025 21:47:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B9BBA6B00C9; Wed, 2 Jul 2025 17:47:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B72BC6B00D8; Wed, 2 Jul 2025 17:47:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A888E6B00D9; Wed, 2 Jul 2025 17:47:56 -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 9622A6B00C9 for ; Wed, 2 Jul 2025 17:47:56 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 18C4D1A04C5 for ; Wed, 2 Jul 2025 21:47:56 +0000 (UTC) X-FDA: 83620662552.05.8341FC8 Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) by imf17.hostedemail.com (Postfix) with ESMTP id 3368B4000C for ; Wed, 2 Jul 2025 21:47:54 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=U9KlTnpG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.177 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751492874; a=rsa-sha256; cv=none; b=PeneW3lPYs70CklprRBQ8hEWYVE8Q+GWS5NgbW7IfDxI+cJjKxaMUGwzoSRkiLoQLwOaO6 yUX4dyq6fgiSLpg9TsidQBaxuj84pdrYmmwJ0O+DUVbWohGKdP4VJnszJrMi8Qnz26+AK6 93ElTbGsJv1Tg1M6/nXiNL5hf6WDrN8= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=U9KlTnpG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.177 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751492874; 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=NzvjFSwko+dMrc+VXfpopyy6igCQQKgZWqJ5p1e5f6w=; b=t17+2bVGHd40BPkI7al+WAlBoKm6y6C5hPJ+esF1Ffl2hlS5FAgNbVED3Y5kHlly3qduxA OTSiCHhXFZe705NsZZavqf+ycfzvoYgU+nkQ3o3RKW57SAo084gbkryrvyJkRBE28B5cNR Dc8b/GmHTNHes7NIc9JIoz0GtV1IXH8= Received: by mail-qt1-f177.google.com with SMTP id d75a77b69052e-4a5840ec53dso89437391cf.0 for ; Wed, 02 Jul 2025 14:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751492873; x=1752097673; 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=NzvjFSwko+dMrc+VXfpopyy6igCQQKgZWqJ5p1e5f6w=; b=U9KlTnpGsE+l39guuGAuMEH9j3qAdHG/qSqec34Y0DZIKhXUuER+/r0qifoFxKkkCZ s3whRg1yT4xLRbofR+i7SF8HeiPiiyszXEOjAP4tjfz4CCgWO7nJiVKXmFPTH43SWuxL dK1O5vgzUwMMTEZY858OVDYQ+kWBl3pemiwoewt9NQkeEWxNEJHBP69ykARaKYVOwiRa 5dWFjpNHwxICreHFE9KP73UlUURJwkIf8Ta6g+sZ0n31ZI0acsF/k5KRW9yyxR6Xpn7C GICfk818/IFyvGrRGi1NWx8DCXFjO6UQZ8GEgK58UV9yI3ykbylPMelvHOHqU20Vg3fa imww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751492873; x=1752097673; 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=NzvjFSwko+dMrc+VXfpopyy6igCQQKgZWqJ5p1e5f6w=; b=lCT2wUG7BM1ZMce7Xp0Rjk9H4xEPQoe5K/dETJWsqppi5gtsfsnlfYFlnYMclMCR1f /lUEv4HrKopSqWhKrNnEMNU8wxRnJOVfQB1ZYNMRtA6w3jMK9CjhJ6Vzdp6tFYugR11+ o495GmuZhsW3x1egK3rQ698k2i1QuOBNWRPvK6eVOfsGlksJgwNqisPDstGTl1yO5B4b bs+akO1/kVlvgV7hdfPR/NH3CEQCzJ3j22xRxVeXvovidzvbwpkTJfUQFLic22CZN/V9 6/zfLA/dJ/R50WhdmEzWmqg6oipVM83VhbpZbH9fu/Bj4OYrKvBWQ0vFsvWD8bggduxP qzFQ== X-Forwarded-Encrypted: i=1; AJvYcCXDUP6uAt7iTUi+Z6deFTSdqBN+Sn9lcbLdwPnKuOASsckaSqw/y2fy376EHNuAqnnmiwfRskzRJw==@kvack.org X-Gm-Message-State: AOJu0YwvrAmfFp3MjRHOjtS3dA6AvmaWoxEg9tTk2FLkoSZcksBmyVh+ qiw42+exHGp7RIs1nBUrySXHzQPuAjIJNPpzZz1J56dZdoToKiA1LWxADOxBXAevix7A3hubQjB 4D5EBpfRsG0TXR/pTw+yUHJqOjFVL5HI= X-Gm-Gg: ASbGncvUDfBNA7LYYgl1YDC770E6haue/fZwMb13EnKURWEpI7RIfhsPIehdLm2qtQv ltYGJcJ3qxvnrzckm43SMyiR/6vi7rd/EeWw+vazsYqBnyyjUFXbAPbDY191+9plgUICLDSYhoB +SYD66roxWbLljAEoys7t2TnkqW9qr7xtYV7Tsu6RqArRpyINUpuBjnHSptae/T32LBTgo6Q== X-Google-Smtp-Source: AGHT+IG8NcRgD8HjsYiMmdTDaNKZPb9NcZq/V1BCtOww+6YZ0E97J6rokogv4y/jJOKonqENm32mK1l2oO6j6tLbRnY= X-Received: by 2002:ac8:7f88:0:b0:4a7:8916:90a1 with SMTP id d75a77b69052e-4a97694b788mr64158191cf.22.1751492872931; Wed, 02 Jul 2025 14:47:52 -0700 (PDT) MIME-Version: 1.0 References: <20250606233803.1421259-6-joannelkoong@gmail.com> <20250609171444.GL6156@frogsfrogsfrogs> <20250701054101.GE10035@frogsfrogsfrogs> In-Reply-To: From: Joanne Koong Date: Wed, 2 Jul 2025 14:47:42 -0700 X-Gm-Features: Ac12FXym-R9az5mneQ_EpRVW06KPBGyYF3nzRvjGnvd59Swbs2wunS06cNQoyGo 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-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 3368B4000C X-Stat-Signature: zaqs5q6b3mb39bpce83npxjynm64mb7s X-HE-Tag: 1751492874-358636 X-HE-Meta: U2FsdGVkX1+yFvyyvVlOd35hu2cNcfqcNs0j6p90n5NlNgxYlHHqfyzIMniwX61UcViAD/3YS/IqA97CesYHuBjeTjnfhAvX9SlxlxiwXhj5UUf08Lj0ReB12STpr1d5E/kbl2TqQmmE3UtiejfQTjpoI1cgsBt7Oqsm8tTb8oHaJ0DaKzf8P0Bc/SJd7DjzTq26nA1I39jJnNR46vbWRAp1rue+TwL1mmFK/h/i81dghVxImb/fpePsu8zgbWIPo/KhUS6bLANEEZGsh5mF3bJY0fCkyBWbMy7hmJya9vl4EArTHOyDrcPjHLsPXD1OhLNTfaDf+AqEzV+aAOivLtpszvzCiSM3lnjBbUAxXb07dP3+l1qUKLhB5dFab3Mn0dX7d00RuH3Gx5/qrUwcpwv8DGWz2IcT8X5S5gnWd6atyGUYJH94/x2HG/5gSDtyIu8blVp9QW2AaB8Sbbml37zZcRNxK6bWaTIBBrabjLcRICcSStpQqbVOvs41IynVOJhDqgyC3ZuyE9mLd2cry8I0QcDBB+C+3Nbqs9lvygA30IRozetJarbyHvZ8TDfvLGTRCedxRDFkl7V7ql/NkkOE5HRe2qtedCsGhXMROs6dcyAZY0opdbhGhL2uSfLSgz82wFTcPgDN2PMTuw/1JWIaTCh1jyXmEY4rqZmhgLeHcT4AX0nKD4Ld91qqljAAgaXhAInbPv04gQVONPlFXs4NbQpWMWWKcouywYVI0tJGua7KPHdlDuR9a/uAy2LtVkMvuhMrR/9A7u5s7eN4n0lrw5CSuOvr/YNZ/jtjsxtVa65/xJxoZen3ivSjO5vnZkuPOtkjJ9To4EH9r8u8kFA98jo7Vcy/+8R8HYBSwwkdCimZGIMwbYvcn66z0c8WONTC+/KzZMYWkQz3TKAhZcoeXxiMHBNHUeW00Gmd4fUWthpWVCIxayjSYE6AJgFNAdNVfb8/rWD16DRrQPa cjJ8Lm5I xiwK7TctlhcsHrxg25bAMbD2PVbxjRCDyI1PCJocGHCSRA9+Hd7MjyxAdYHPCZtCLJ04gmqkGvizsaQuCisPqo9ck4ghKjt2If31yWNoDnGZiBoGAYD0qvTBB+U/KOuo9CYM4lWilwQl9I6NlsY1ESIzofzrn2NF6/RIcXoMjihnTK+3xGX0gVAiVQGjKS8gDObhxSqpwO0dE6D2LnxXl2+A7QJ/JzX2GA54RSlmjEG+7/AnJdVbswNcS2tFE9nJu++j4yOrgCZ7rwXPgmYYujgceo/dTqDsggFFGlzBjMLclIWFvrU0dASbgVZ81AvpPFZONvrMHZJxWl4znk7imRaXO+8GUZJOqso/2KCDi9V47zqhJViCeY9XFMpESXr1k3nmDzMlOFYjP1yIwgiemmjTB4THJ8sZvr2wbFWvAJV3gXcPP58G2MQ71LBe/NPmp7c3qKzJQQBD/sDlovELY+VEBLxWcP3TReshnvDFaDaCvYXa7bHKRSc3FNE3lr3d3jEQd 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, Jul 2, 2025 at 2:36=E2=80=AFPM Joanne Koong wrote: > > 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 filesyst= em > > > > > > which implement ->launder_folio today. Because we could just m= ove 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 wha= t I > > > > > see, there's only 4: fuse, nfs, btrfs, and orangefs) just move th= at > > > > > logic into their .release_folio implementation? I don't see why n= ot. > > > > > In folio_unmap_invalidate(), we call: > > > > > > > > Without even looking into the details from the iomap POV that basic= ally > > > > doesn't matter. You'd still need the write back a single locked fo= lio > > > > interface, which adds API surface, and because it only writes a sin= gle > > > > folio at a time is rather inefficient. Not a deal breaker because > > > > the current version look ok, but it would still be preferable to no= t > > > > 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 fin= e > > > > ...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 happen= s > > > 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()). Or actually I guess the one deviation is that with ->launder_folio() it can return back a custom error code (eg -ENOMEM) to folio_unmap_invalidate() whereas release_folio() errors will default to -EBUSY, but the error code propagated to folio->mapping will be the same. > > > > --D