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 3092BD5D688 for ; Thu, 7 Nov 2024 20:20:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9DF2E6B00A3; Thu, 7 Nov 2024 15:20:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 98E7E6B00A6; Thu, 7 Nov 2024 15:20:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 839906B00A7; Thu, 7 Nov 2024 15:20:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6360F6B00A3 for ; Thu, 7 Nov 2024 15:20:05 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D6E88AB4F7 for ; Thu, 7 Nov 2024 20:20:04 +0000 (UTC) X-FDA: 82760413554.09.B958DBF Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf23.hostedemail.com (Postfix) with ESMTP id 292A5140018 for ; Thu, 7 Nov 2024 20:19:38 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=rbWCU6p1; dmarc=none; spf=none (imf23.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=1731010718; 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=WBdml7YjmERUT8SVBwJP9R+7xZP2+k1OGM6A0zqovvs=; b=qQx7mhFoE8VW94q50kWrXD3hek6j5nep/Dnuf3/lCgz+iJ0m+f5C2wW+7P/nDkx2JkXKO5 /BTy0SsfpcdZDWPwAxWVodysKJg7z29mWUPHMO71DVKM2wz7ZaEuBSte5n14t6y44QFQyL pNRrYnM3P5mnPYeLsTsY3dNK4jtnuiI= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=rbWCU6p1; dmarc=none; spf=none (imf23.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=1731010718; a=rsa-sha256; cv=none; b=hJiGSBDPp+l9libs+KuYN/f0oJpM3QfyvVulmNA6ppz5IJMXeeegyNLbDXa/vnyFkszCYb HjwiWqZOG/3400RRD2oEr7r/uexO92oHVe+MPXqwlIB5vd8BUrqacx4kjCpTyexnMfHOc6 ehYAR/Zv9MU5Ox5jvYBta721G0Adj+U= 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=WBdml7YjmERUT8SVBwJP9R+7xZP2+k1OGM6A0zqovvs=; b=rbWCU6p19KhlwSTEPtF5J0EJBt LSf714Sv1wrXB29l5QtvRIF10xdPqfq15PfALw27p3i31Hc3o8MrDU+Mh8TVlAqthI+pNzUIbzkZG ncEoWd5qQ5MgfcM89DZlpRn8JvEZxf42YTDyi3aC2OOAHSw2AaqFCym8ELxz//aKjzOzyqIr67ikL o7uUiltBB5NDbQaoz3ryf9+N/t1W/X7F4xKL1MaCFfMWHrJaZicsgv1s70p5nfpQ1JfpKl/rY/Bar cpBq8eRUhPhKGbAMcsZy4H8rfc9Qg8RY7xepQpgXBUSbQ/Qh1sUb6FBugvS1T7SCIsu4IAaSrv4QA iZ5fYy0Q==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1t98z2-00000007Kj7-2nAz; Thu, 07 Nov 2024 20:20:00 +0000 Date: Thu, 7 Nov 2024 20:20:00 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: linux-fsdevel@vger.kernel.org, "linux-mm@kvack.org" , kvm@vger.kernel.org, Zi Yan , Christian Brauner , "Darrick J. Wong" , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Thomas Huth Subject: Re: [ISSUE] split_folio() and dirty IOMAP folios Message-ID: References: <4febc035-a4ff-4afe-a9a0-d127826852a9@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 292A5140018 X-Stat-Signature: bzyw684cjcp9synmagnc9eejdkkcfa5k X-HE-Tag: 1731010778-214817 X-HE-Meta: U2FsdGVkX1/znO5dy8BBDUUtHeN3O+MaFU/NPU8vV7QSziti7JEGqXqg3eYfbpedt24VBrNVZFfvmgE+7Bs8xNxE3sEC+bVyrNcKNIBkkbkx/OKi1BWKHAhjQ/fNRhAjRrE4mpEatkH9qzsX48eqh9daN+ldCZNSQM+qHapAMSJrgM6rF0Xqh+otblRuweTOQWILc7G0poiizE/IoJK/OlEhFUh8353SxsvCKnZHFrsH3bQVhRaQni1aSkGz6oAWrlXx0s+A43maBWiNDMBe+MlcBwONhTBjZT+zQQkdysdmrssx3Xt3TUcYonv/GWhubl4rm7M+ya22fbS4BUOJO2J1AsVJ6jssafsEjaHVICU2TTSEHHlIgP/S5QpysZqv5vZ0nx7uZhK4BrjVQKYmCmYg8HchC1/LArqxLvhI7F8P1eJPl663GQNx8un/p/IPsxQE9MlwpKO5mYy+AzDLy/EJAHMTvGqohm6wqP4CmD5/vxfEBlZYhrW+lZbR+uYaa/RyVaXxtMKoQYpUDmJOTHcz+OcBH9JPVeGFVGxs5bR874I8EKy1yp1vB5BOoQeQ/vKcfqzjolDjqo2eOBxAdXlyokVWXrRvpVmUgHGpB/jL3bRaNCMb3LnbxUDBwvm5aw2O5b4MvmLUgxK2NeHExczDbXeQN0Dc/xtUrJTBi9VQtcWyiGZ3Hz4He9kAp69t7LHUK7pXD1bn63z+GgJzZpIcpLUX8m+E72lgbybh7rurP4be1gG2shAYRYTyqhZyIvSuAuDPz99QbyPmWcqwqaYjoKyTUSeHFhnF8/0i7FRhIiSlnKG/tiDtvY2Yb/V+K/ESUNlmiFqsxXZxdyQL0kNoOgnq8G6S4xABR64U6Dsg1tpm32+n2cBTRnXfka+WXkjJETdAXIgcKHiFT+j323jo5eFYBLHLDJPUPukHdHCFB8gIjS+7P2TVIWiBXrnq7zteHWmB+kaPbru2vU4 qhgNeUdR PabrhoUs8I2phyr498y/lKfX5WOQXAqBq7xrGDb/zaTfL4BV2wHvitweY3LOBOPxP1TDcVmpQ61BUL/xI1JCX3VkztAVkXnTrUkqNKEeY1/j1hla0E5PMfLGtbtTUDZ1rLJOQ6W9HUYhiD9YGHymrx0NknQhldFGYUsy+u+eL8D04/4KeNw54+YYF46QTdpRkbSMrP9nPb58HbKPFH99ht1Fd6HxNBGhVJBpF13dW631cNwdir4yxQk9ZQaoVkSUFw7CdjPcvCWTOls0kMU/LShXLClAQtsZ3D6pnrBwa20jhm/7SrdxICDbBtVAEJOXDM06L X-Bogosity: Ham, tests=bogofilter, spamicity=0.006322, 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 Thu, Nov 07, 2024 at 05:34:40PM +0100, David Hildenbrand wrote: > On 07.11.24 17:09, Matthew Wilcox wrote: > > On Thu, Nov 07, 2024 at 04:07:08PM +0100, David Hildenbrand wrote: > > > I'm debugging an interesting problem: split_folio() will fail on dirty > > > folios on XFS, and I am not sure who will trigger the writeback in a timely > > > manner so code relying on the split to work at some point (in sane setups > > > where page pinning is not applicable) can make progress. > > > > You could call something like filemap_write_and_wait_range()? > > Thanks, have to look into some details of that. > > Looks like the folio_clear_dirty_for_io() is buried in > folio_prepare_writeback(), so that part is taken care of. > > Guess I have to fo from folio to "mapping,lstart,lend" such that > __filemap_fdatawrite_range() would look up the folio again. Sounds doable. > > (I assume I have to drop the folio lock+reference before calling that) I was thinking you'd do it higher in the callchain than gmap_make_secure(). Presumably userspace says "I want to make this 256MB range secure" and we can start by writing back that entire 256MB chunk of address space. That doesn't prevent anybody from dirtying it in-between, of course, so you can still get -EBUSY and have to loop round again.