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 8CB01C48BF6 for ; Thu, 7 Mar 2024 04:45:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 131886B0101; Wed, 6 Mar 2024 23:45:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E27E6B0102; Wed, 6 Mar 2024 23:45:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EEC8F6B0103; Wed, 6 Mar 2024 23:45:25 -0500 (EST) 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 E12946B0101 for ; Wed, 6 Mar 2024 23:45:25 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 978141C12B9 for ; Thu, 7 Mar 2024 04:45:25 +0000 (UTC) X-FDA: 81869004210.03.F516704 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf13.hostedemail.com (Postfix) with ESMTP id 331982000A for ; Thu, 7 Mar 2024 04:45:23 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Cu5UtBI+; dmarc=none; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709786724; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=r8w2DNfyKL2/tLJTtAySKLQRqT812RnWeFEltkFTF8c=; b=yu7upFeEyEJaSMa2FjGYR/CyAE9m3WWFcFzKT74O+eoJ6CacUX6lv5edyUfMgHuFCiK0um 04AwbG2znvlZPqbVokbmSftxvrTRRe0yKzHDLrjpxmDEDptOwyM6LmslbWQL1JscDoDxhY ByLUMPpLjQDKsiW85suIPzlM1i0AES8= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Cu5UtBI+; dmarc=none; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709786724; a=rsa-sha256; cv=none; b=L342EtX5/Z5zEfgs+qgtj1P+URFI4WiHGQCoU6GprgGIj0SYJLOQciaQmCDspjjV68lVy/ 4Ku/s7Tsr4Ry41xtivphKGcEJhSSHn2qeZsI8mL8B9F6v+L56rfOBg06KlEtAtCO9WmOkk 35FOXDxDuj8YEqfBL76f6IFi/V/5l1U= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=r8w2DNfyKL2/tLJTtAySKLQRqT812RnWeFEltkFTF8c=; b=Cu5UtBI+YyYOWL2AUGLQTNt1FK kGRmBYcZ5LzKErtlKR8XYNMFxZjzP031zLs0ZtzzWdiCk8zS0Z1YfnvNAeLT+1UYi69cFr/k5MT7q 8ZHbNNKiTYzCwdnJrOTD1V8pn6V1r79vE3MopVrLyUdNJPu6dr/19HywX3LN9Ac+VrvxspVZdAqtu zAbfZG9+0Sem/3BRus9T0O98YG/B+Qb1G3llp8PxeJCp/CEU4vmQzHAlLoVpbtkX5uZoKMPULH597 71xabJgGXVWMg0YA5p5KllDvbcofYVvG1AYoDF1dON1Gz4UwFdJZ+Pt9CpZxksDgjiHvwjcmgIu5b ybLdNwUA==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1ri5d9-00000008NNo-3J6E; Thu, 07 Mar 2024 04:45:19 +0000 Date: Thu, 7 Mar 2024 04:45:19 +0000 From: Matthew Wilcox To: David Howells Cc: Christoph Hellwig , Andrew Morton , Alexander Viro , Christian Brauner , Jeff Layton , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, netfs@lists.linux.dev, v9fs@lists.linux.dev, linux-afs@lists.infradead.org, ceph-devel@vger.kernel.org, linux-cifs@vger.kernel.org, linux-nfs@vger.kernel.org, devel@lists.orangefs.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] mm: Replace ->launder_folio() with flush and wait Message-ID: References: <1668172.1709764777@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1668172.1709764777@warthog.procyon.org.uk> X-Rspamd-Queue-Id: 331982000A X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: qnpjy5s8aiug1z15bhtkkh7qg6uwitdf X-HE-Tag: 1709786723-275577 X-HE-Meta: U2FsdGVkX19Vx13I9Pmyu/wW4iG4y0AY+AjUv0aOySAIx4yKVdB5UlOmL8FCQmY0UGYGOP0ZrvYXisn13MNVXzEIwqYiVBwzO10TVAWkH0wgUFK1CgI2AAqbkVOvJEe/7H0PpJGteKi9/oEhQODnLqxeHV+n0B+rQpgeIJMkSEG2F/GXjjOHlS+X6T1JBW2A+EC/cWdXU5gWNDKub20L0WYKGq5DrI2te/Obc4Z1t2HQqDnkwlF3Nq9QaeXcGf/ND7hG74dSLPUnDSnwALUAIhAqudVbVz68kZoXeMTkD3R5b7AvaMgqvGg9MEig5Nxx3Rz2Av8E2RxPMR6mIwlEeLaWB1tnPMV4O5FCejYOTNvj+iYAJ9bI+Brjh2o1JjExwCmFLhqwJSCkXW9DP5Pj9b8TXuL5ZmaFbiq4gpBtWDuzqYGDisPLwiVrvL6FIP9XtJhabZJvZa6aWElbmzKP32BipvVG6zUR0Cfob5KFri+xGTNKaQWl3R4B8S2DISQs+/CX9I/jK9hfYOErOrcvI9kG7xGUpLo4LoDJ+ywmogG4tzPscd4uH6hyhEilF7eIe6Xu6fDftEJJnWYhHbjo3GxmxZZwpa1XaqmfOvRG+VaJlRy7eP4e0ogV/CY5yn+NnDe3IWerBeadIvIhHdmRqiDnoLedwFMrjHrZ+daVZkfeXk6iUZ5d4251J/ZoWw1zqGqSJhTM3ubymA5yx5uCWp/13HII/q7ZKN+iSQtH3Es9tzi32Hg/ktmmZ2X1nU8QRg+uPyKiufL4Wf7CSs2PrJzpjs01YoteQ0AQkCbRpkHkmOMbLfK0iisgFDgYWLT0R41TiZtXyx2Qm+dw96qsvm47LCA2qAyw8+0+t7JVxKWwptSaBRU2xyK2syeBYBuC 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, Mar 06, 2024 at 10:39:37PM +0000, David Howells wrote: > Here's a patch to have a go at getting rid of ->launder_folio(). Since it's > failable and cannot guarantee that pages in the range are removed, I've tried > to replace laundering with just flush-and-wait, dropping the folio lock around > the I/O. My sense is that ->launder_folio doesn't actually need to be replaced. commit e3db7691e9f3dff3289f64e3d98583e28afe03db Author: Trond Myklebust Date: Wed Jan 10 23:15:39 2007 -0800 [PATCH] NFS: Fix race in nfs_release_page() NFS: Fix race in nfs_release_page() invalidate_inode_pages2() may find the dirty bit has been set on a page owing to the fact that the page may still be mapped after it was locked. Only after the call to unmap_mapping_range() are we sure that the page can no longer be dirtied. In order to fix this, NFS has hooked the releasepage() method and tries to write the page out between the call to unmap_mapping_range() and the call to remove_mapping(). This, however leads to deadlocks in the page reclaim code, where the page may be locked without holding a reference to the inode or dentry. Fix is to add a new address_space_operation, launder_page(), which will attempt to write out a dirty page without releasing the page lock. Signed-off-by: Trond Myklebust I don't understand why this couldn't've been solved by page_mkwrite. NFS did later add nfs_vm_page_mkwrite in July 2007, and maybe it's just not needed any more? I haven't looked into it enough to make sure, but my belief is that we should be able to get rid of it.