From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E85C0423E96 for ; Mon, 24 Aug 2026 13:20:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=96.67.55.147 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787577621; cv=none; b=syMaNEylC16VYwrZOZpDiS6qRFm2WXwCmeWKZrgcuqqMn7+ofDmprC09kbuDz3L7ZqRjVqZ+qTncN5SnVPNJufmNqyyVhrC/pztzdMRApGo7SZcn8rUZ6TJqeebML/rwOcxcRML+eAIwCaiJYjZsl8jPptKJnPOr5NqJIuHVaZI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787577621; c=relaxed/simple; bh=fI5J35zZVeodU54e2f/003tiost3YB+AH7moLkYpx9Y=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=Oien7rqvUZauxN1wYtQyfUBRpRjzCwfSWQWqqUmP73fDG2xrgStFE1FC7ocM52IyCU78gr0WLdLU3vzXfcZ30FAKBZ7mzWQuKy95ZPAWhPF5ZGtz9XgunSyA9HWmOXjQyBd/KNZH1zn3yfOFU5ubXMekM1qyVLtK7HUdUNpdDxo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=surriel.com; spf=pass smtp.mailfrom=surriel.com; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b=GdsbHhsq; arc=none smtp.client-ip=96.67.55.147 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=surriel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=surriel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b="GdsbHhsq" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=surriel.com ; s=mail; h=MIME-Version:Content-Transfer-Encoding:Content-Type:References: In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID; bh=fI5J35zZVeodU54e2f/003tiost3YB+AH7moLkYpx9Y=; b=GdsbHh sqngHZZica6D95+3QCPlSq6hHkQrPU7DKwvRAYadqPHQqEICABi0iS03N2JcLGiFNdDipD57s6AbY eghePhj8FkWax4ax7Fu04yWLrA3QXXla6EoVVAG7wwto4SkLrtKR9vlfwqc4G+NIQz0uWqGL73LT4 eSwf5CRhj8zPSxBRtHq64orT8bRBhDrodNE5hwHFso0yE7cKMZULpvBltJwLEe1CRDJ7678ywCaah TPFRdqS0ROjzzxIeMzuT2BOfMkC0aio3htpyXB80Hm8QH+QkUyN2Ozhk0FHXLpQcySjwDHqcg/1RO KOHmVleepqzG448gLmv6MKrw9hkA==; Received: from [2601:18c:8100:a0e0:5a47:caff:fe78:8708] by shelob.surriel.com with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.99.5) (envelope-from ) id 1wyUar-0000000328N-23lS; Mon, 24 Aug 2026 13:20:05 +0000 Message-ID: <99b9a43505c0dba4c656bf950869f76f95e399ce.camel@surriel.com> Subject: Re: [RFC PATCH v3 3/8] mm/gup: split follow_page_pte_commit() out of follow_page_pte() From: Rik van Riel To: John Hubbard , "David Hildenbrand (Arm)" , linux-kernel@vger.kernel.org Cc: kernel-team@meta.com, Andrew Morton , Jason Gunthorpe , Peter Xu , linux-mm@kvack.org Date: Mon, 24 Aug 2026 09:20:04 -0400 In-Reply-To: <42d8fc20-4ee6-4bed-b2b4-3f968bd29f5d@nvidia.com> References: <20260811025157.1632867-1-riel@surriel.com> <20260811025157.1632867-4-riel@surriel.com> <8a9d5a6f-a7c6-468f-8b50-a7aa2b4dea2c@kernel.org> <30b747de6202cd875b7669f8d76ad8ded5c0a4e7.camel@surriel.com> <3b8cb743-702a-4362-9abb-7c30e687c3c2@kernel.org> <42d8fc20-4ee6-4bed-b2b4-3f968bd29f5d@nvidia.com> Autocrypt: addr=riel@surriel.com; prefer-encrypt=mutual; keydata=mQENBFIt3aUBCADCK0LicyCYyMa0E1lodCDUBf6G+6C5UXKG1jEYwQu49cc/gUBTTk33A eo2hjn4JinVaPF3zfZprnKMEGGv4dHvEOCPWiNhlz5RtqH3SKJllq2dpeMS9RqbMvDA36rlJIIo47 Z/nl6IA8MDhSqyqdnTY8z7LnQHqq16jAqwo7Ll9qALXz4yG1ZdSCmo80VPetBZZPw7WMjo+1hByv/ lvdFnLfiQ52tayuuC1r9x2qZ/SYWd2M4p/f5CLmvG9UcnkbYFsKWz8bwOBWKg1PQcaYHLx06sHGdY dIDaeVvkIfMFwAprSo5EFU+aes2VB2ZjugOTbkkW2aPSWTRsBhPHhV6dABEBAAG0HlJpayB2YW4gU mllbCA8cmllbEByZWRoYXQuY29tPokBHwQwAQIACQUCW5LcVgIdIAAKCRDOed6ShMTeg05SB/986o gEgdq4byrtaBQKFg5LWfd8e+h+QzLOg/T8mSS3dJzFXe5JBOfvYg7Bj47xXi9I5sM+I9Lu9+1XVb/ r2rGJrU1DwA09TnmyFtK76bgMF0sBEh1ECILYNQTEIemzNFwOWLZZlEhZFRJsZyX+mtEp/WQIygHV WjwuP69VJw+fPQvLOGn4j8W9QXuvhha7u1QJ7mYx4dLGHrZlHdwDsqpvWsW+3rsIqs1BBe5/Itz9o 6y9gLNtQzwmSDioV8KhF85VmYInslhv5tUtMEppfdTLyX4SUKh8ftNIVmH9mXyRCZclSoa6IMd635 Jq1Pj2/Lp64tOzSvN5Y9zaiCc5FucXtB9SaWsgdmFuIFJpZWwgPHJpZWxAc3VycmllbC5jb20+iQE +BBMBAgAoBQJSLd2lAhsjBQkSzAMABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDOed6ShMTe g4PpB/0ZivKYFt0LaB22ssWUrBoeNWCP1NY/lkq2QbPhR3agLB7ZXI97PF2z/5QD9Fuy/FD/jddPx KRTvFCtHcEzTOcFjBmf52uqgt3U40H9GM++0IM0yHusd9EzlaWsbp09vsAV2DwdqS69x9RPbvE/Ne fO5subhocH76okcF/aQiQ+oj2j6LJZGBJBVigOHg+4zyzdDgKM+jp0bvDI51KQ4XfxV593OhvkS3z 3FPx0CE7l62WhWrieHyBblqvkTYgJ6dq4bsYpqxxGJOkQ47WpEUx6onH+rImWmPJbSYGhwBzTo0Mm G1Nb1qGPG+mTrSmJjDRxrwf1zjmYqQreWVSFEt26tBpSaWsgdmFuIFJpZWwgPHJpZWxAZmIuY29tP okBPgQTAQIAKAUCW5LbiAIbIwUJEswDAAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQznneko TE3oOUEQgAsrGxjTC1bGtZyuvyQPcXclap11Ogib6rQywGYu6/Mnkbd6hbyY3wpdyQii/cas2S44N cQj8HkGv91JLVE24/Wt0gITPCH3rLVJJDGQxprHTVDs1t1RAbsbp0XTksZPCNWDGYIBo2aHDwErhI omYQ0Xluo1WBtH/UmHgirHvclsou1Ks9jyTxiPyUKRfae7GNOFiX99+ZlB27P3t8CjtSO831Ij0Ip QrfooZ21YVlUKw0Wy6Ll8EyefyrEYSh8KTm8dQj4O7xxvdg865TLeLpho5PwDRF+/mR3qi8CdGbkE c4pYZQO8UDXUN4S+pe0aTeTqlYw8rRHWF9TnvtpcNzZw== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.2 (3.60.2-1.fc44) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Sat, 2026-08-22 at 14:31 -0700, John Hubbard wrote: >=20 > Its workaround is folio_set_checked(), which defers the real work to > ext4_writepages(). If ext4 can't do the preparation from inside the > dirty call, a driver can't either. >=20 > So for a file-backed page there's nothing the driver can add. What's > missing is a way for the filesystem to be told before the device > writes, and to revoke the pin when it needs to, which is where the > lease proposals come in. None of that exists today. >=20 > And yes, unpin_user_pages_dirty_lock() is in the same awkward mess. That still leaves the question on what to do with code paths that rely on get_user_pages(FOLL_WRITE) to set the dirty bit on pages, and then do not set the dirty bit themselves after they write the page. Would it be better to move the dirty bit setting till after the write (to the page) has happened, even if that code does not queue up a filesystem write? Does unpin_user_pages_dirty_lock() need to call Folio_set_checked() ? You've made it pretty clear what is wrong, but I'm confused as to how we could improve the situation, at least without waiting for extensive filesystem changes first. --=20 All Rights Reversed.