From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 8246B4F3EDE; Tue, 13 Oct 2026 11:59:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791892799; cv=none; b=M4darvmRtC3j/YPkrF9ZOm0z9d0RC/cMe2FkxdGr6a3fMOWR/YEPQXLSN8LydiLttY8D8NSr/o6v46cQaurQvA6Mc8f/sfASvUPay2lPggXZXmU+7N9EmLGwqWNYfWsVRgN+lga4wMg8SsclOfh8J7aoDQYr3xWhr7MldHLa39o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791892799; c=relaxed/simple; bh=PVBAqCAX2BWH/Zl9U92cd1oaLwgbXMTR0LF2p0sfSYM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bOJr2oIvH5Us+sLZ3cPuOFz5NmdcxN2U10Kkr6mXVBBl47m6/XoO5XIoeYXlxSrypTtIKs8xi/6WNHpoL7JB7eq3ApdhF0ZJzzaZmEUpBtH6iuCAeLMqkjq+hYmiB4iyV3LfRe6bbBvnyTci+J7RgQgrHGy7uubRrhHDorAHMuU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=J1vCxpG4; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="J1vCxpG4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3D181F000FF; Tue, 13 Oct 2026 11:59:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1791892798; bh=8YOhnB3A2QNXZu8fcAIUX5v5/qWH3yarQ2Ukkn+WsY8=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=J1vCxpG4Gc0tkAMdnwfggkLbvW5x4Jl7ZXEeVEu7PoJcLYgXgb+iYtuYd05gViis7 kW459Ugie3aljwlyZ6a3TRZ5TEYB+Yvc5QLxsAX4doDV1phG89yFFmSmvkOlL7RhiK 32+aR52NTCjfhZHeb9XIV3+QRQ117cXVOYglnZaE= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Rik van Riel , Zi Yan , Jinjiang Tu , Dave Jones , "Matthew Wilcox (Oracle)" , "Christian Brauner (Amutable)" , Sasha Levin Subject: [PATCH 6.18 002/621] fs: Free any excess xarray nodes in clear_inode() Date: Tue, 13 Oct 2026 13:29:57 +0200 Message-ID: <20261013112920.919091677@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261013112920.855194808@linuxfoundation.org> References: <20261013112920.855194808@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Matthew Wilcox (Oracle) [ Upstream commit ee3f011250104129893d8e9599147e457d4d7280 ] For many years we've had a hard to hit leak of xarray nodes. Hugh documented it well in commit 786b31121a2c. Recently people and syzbot have found ways to force it to happen with madvise. Rather than fix the leaks where they happen, just call xa_destroy() which has the side-effect of cycling the i_pages lock. Cc: Rik van Riel Cc: Zi Yan Cc: Jinjiang Tu Cc: Dave Jones Link: https://lore.kernel.org/all/20260121062243.1893129-1-tujinjiang@huawei.com/ Signed-off-by: Matthew Wilcox (Oracle) Link: https://patch.msgid.link/20260623192850.1595958-1-willy@infradead.org Reviewed-by: Rik van Riel Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin --- fs/inode.c | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/fs/inode.c b/fs/inode.c index 44891fb7cd436..24762fd1f2f77 100644 --- a/fs/inode.c +++ b/fs/inode.c @@ -745,21 +745,18 @@ void dump_mapping(const struct address_space *mapping) void clear_inode(struct inode *inode) { /* - * We have to cycle the i_pages lock here because reclaim can be in the - * process of removing the last page (in __filemap_remove_folio()) - * and we must not free the mapping under it. + * We have to cycle the i_pages lock here because reclaim + * can be in the process of removing the last page (in + * __filemap_remove_folio()) and we must not free the mapping + * under it. We also remove nodes which are empty; these + * can occur in two different ways. The first is that radix + * tree expansion can fail partway and the second is that THP + * collapse_file() can allocate some temporary nodes and not + * clean them up. */ - xa_lock_irq(&inode->i_data.i_pages); + xa_destroy(&inode->i_data.i_pages); + BUG_ON(inode->i_data.nrpages); - /* - * Almost always, mapping_empty(&inode->i_data) here; but there are - * two known and long-standing ways in which nodes may get left behind - * (when deep radix-tree node allocation failed partway; or when THP - * collapse_file() failed). Until those two known cases are cleaned up, - * or a cleanup function is called here, do not BUG_ON(!mapping_empty), - * nor even WARN_ON(!mapping_empty). - */ - xa_unlock_irq(&inode->i_data.i_pages); BUG_ON(!list_empty(&inode->i_data.i_private_list)); BUG_ON(!(inode->i_state & I_FREEING)); BUG_ON(inode->i_state & I_CLEAR); -- 2.53.0