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 70B27D43374 for ; Thu, 7 Nov 2024 16:10:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BE1A96B0085; Thu, 7 Nov 2024 11:09:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B91486B0088; Thu, 7 Nov 2024 11:09:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A58976B0089; Thu, 7 Nov 2024 11:09:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 88C4B6B0085 for ; Thu, 7 Nov 2024 11:09:59 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 380201A08ED for ; Thu, 7 Nov 2024 16:09:59 +0000 (UTC) X-FDA: 82759783680.08.FCDAB43 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf08.hostedemail.com (Postfix) with ESMTP id 35E4C160002 for ; Thu, 7 Nov 2024 16:09:31 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=pcYuprwN; dmarc=none; spf=none (imf08.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=1730995627; 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=r/NDUsG2aDKB3uC6YveYjLlK3F8ZxVs/bPaI8H9TOlw=; b=41K6LC54EeYuPORCk1GUfCEdziEHkoC2QDPB47Ykrp8L0x5cj1/Iuj3Bhhe0yfyV3zYpeN 6Qg2+VwUOM+uyQDFXRHk9mMMLyKueHK68JkBe/nHhYFtlT5UaOKLdhSw6mwsvPEryn7Wbp 9LY5LgJsS7SIptUatLue7QrwNoE2G6A= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=pcYuprwN; dmarc=none; spf=none (imf08.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=1730995627; a=rsa-sha256; cv=none; b=iWFyhzJeLes7YM17CwPeGB/1QlqaGid6xyd0GvWJ9PMk9zNt2WXyMOFBCCkPU/o2SHVU8S 046aFj+nztWOe1Wem6aOsnxXLFAMGYWu3bFII8sSdBtRiSX34hDQtfoxWIPHWnlBVuP1mz LUtfMQLdR6Q83HDIVp4hUcAj3BOIcPc= 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=r/NDUsG2aDKB3uC6YveYjLlK3F8ZxVs/bPaI8H9TOlw=; b=pcYuprwNIEuVYRpI+Y18x0G3mz CWJ38iYNMeOlOMoSCQvWB6y0lcwORd//UD9fSuNnmDmV8MGq96jop1G1ReQTS692mh8S5ctYjCOYT nEYNfb1vyuitmw5A/ESFt4vWerdEqN5w3d0JTMNKzjIkB/hwUmPMNLQdDDGkZPW+j2wrcA045A8RZ 8Rff+qhmOCpluq881RYvXMwO9BH9PboUnOKNzgXWpheUh02PPj3l+ZFsTvTXpI9phcYt2j1b7nvOE hnmZVFaBmgxMCRn1s64a1HrjQxS886luk1mSSawBHjJgIStX78knjRtkEwX+ehJ1XAwRuScidBqOG UGRsuVfw==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1t954z-00000006wmb-3hn8; Thu, 07 Nov 2024 16:09:54 +0000 Date: Thu, 7 Nov 2024 16:09:53 +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: <4febc035-a4ff-4afe-a9a0-d127826852a9@redhat.com> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 35E4C160002 X-Stat-Signature: 9jgwsod69go89qk1xw3i83xxui861jmd X-Rspam-User: X-HE-Tag: 1730995771-235348 X-HE-Meta: U2FsdGVkX182b7l9ksolnVwMaF9VdZHt/ODlSHDJaRoTZNBFuXyqDbPu18GCIhlkMikGxLhs0L4ywvVEBvFNyofOLI1hcDS2D5jlLiUrb9uwx4+0bF7/gUz7Kuz6iNJBPbO+RrNcyPziKWyj3K77VOzmCzON+orLGl2YhHiXEIdRvNcLoBcPU/s8Vpv9GW4lZfydvQ8xUoXEST27mGDjbro4Lso6XNSB78XPy4o1f91gfos/VEtWCiCuQ7H22A/FUgVIYC7620KJZRdL3axgXLx6lLyBrwHU3GSTJHrqM7UZ08eSDlC9OAmzOQMTxq4xw067KGdjJVnbmzYFmv4vnMQbhKqwmwTZ3RfYl4gzz9LtCJDVWf9TAhnBECrbWWTeCkbt9FVPLaG6FNTSFd9gSsyr8gmMs1D1Sue/AUmIIyAxpFRGwdsky17jbAxC4Q46hRrEBMBsPdS4yCcbSFxk1KT+6m5mN8D6Ejx3JtSyE6qRB8mvjbd4luhSp3L1+n2e+t7quYEGGAWbWIBq3aOaKMXURfl2H6FqfOXgz1fEvAO+B9mSITdjxmrs9VH7cV5Bprxnl2gR7ZSX0OARH9Yp+KOik5ouFecnqBVoCRVJYhnTXPA32UHYFfJkki9NNqPXnrliOy/bIfVm8eeUb0fqBVUf9FtiaaD9JN/gtD67jeSRUGXJXcC9aZSxfucOpKiLhXT8sJ4xfcs1tmAVjN84A2f7WQhqkExFMdJW5rvbFF4zjHg1JcL5hnPk76L2BVPrW/ZqFY0QM2VlhGCPU2DsDVDxmVPqF88oKrDfz+VpP4QDpFwV37kMyuNBfr9izR5jtuklCoSSAt62RQdfIKNdwlAYlY2CMawhxP0Tp9gCInCkQOJqf9DtbzuD4axA+TVE1YnFWatHqcMpn6wgxfMv1bsazuomV3YZOWwY4y493lZWRQZjI/EkSYOFyHkZt06JF7Z38h0zTQ8XOnl0XJK FSFGTlqt cw90UuW2XR9/6OgC71959z84d/XGtPjIRKPwPzXo8b7lXWRqTXdOYdPfY7qNMrfI3hs5tYZx9ZoVzx1j2GKAoez/SGLmNAaaWQY0YdX4R2yTkeoD78DAa6M9u/XV/CrCzW9mYf0qDCg41AuyUgpVhRMeXrh6WBkhjBkBJ0YxCvZUo8adoxh/cowodB6b6pg6MVeOvBbkDLh0gOql9fU5juBIu3LSxPQUmfhrZ1l2N1+fbXYRckBA3PTkF+g5btiWUeD1JBUOVE396RUyVgzzaMhvTDd4ohYlq5prAuw1UKqr7Eju2/TuX2a1PtXQd2GOfHhRx X-Bogosity: Ham, tests=bogofilter, spamicity=0.000860, 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 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()? > ... or is there a feasible way forward to make iomap_release_folio() not > bail out on dirty folios? > > The comment there says: > > "If the folio is dirty, we refuse to release our metadata because it may be > partially dirty. Once we track per-block dirty state, we can release the > metadata if every block is dirty." With the data structures and callbacks we have, it's hard to do. Let's see if getting writeback kicked off will be enough to solve the problem you're working on.