From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794585487; b=Nii85W243DjIdcPtsDd9M8LfC4KMc/ewi8nn7E5z/u6fPLD1wdJHcHHKkDoDUHb5YRff SDin9oqLAa9u0vyRHPzHo9ib7GAk5AZRr+LoVR3eNhYB76tXMiFCEpxuBdOnXT7UZ0jCh ZJKPjnyJzFtL8XtY9hNHVR3fXveO3HmL4aSQgmtJ7ZY8tZRcAvNz6Wu4UwvY3bg+qe39v L/g8XhdmJ5kwQ+QDlhJgAQSFxnXDax8RAUDJCt9U3Rr6SVyQBj4RPFfktNVKl6J4fGxBk dSygtqsElPQRUyV6YLrCYbXxr1BHsJ1J46Xa5kPSioFuMPhayFiKBwRvc+/jDRR8dHg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794585487; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Transfer-Encoding; bh=tZ7zrlJ692gL5VeoXOgnpdnv26FxzrS2SiW/5S1BlsU=; b=Vcn9uRXXcAyjTVUx84WE1WAOclvdbSdV4e7RJoUD3i2KjPB1XUa8FnhMxU2CsKU8lgoA YSKxLNKQETm+zrJKioTPdmzZeqVvFtW6tafEh7ZNcgsZmykCUOGbKiPXsG8Om4RiXwJFo YJfSc2gHRpDY6mkFiQcazObgwRDtnDdboxiiBv8hjrPFhUh+HOo1wAddVN4O3DbUvYfmr khlq9Pa8IvfC8Fhr2Z/9cYE4JI4LMedCekvLk1a6x+QuYXW8b3xQXmzQS5diiohv3R4bq mgt4aDpvnzTzPdLv5N5hpvnMY/3rnEbhYR2//T8hoC+zlInMEO0/C9EqbjJkMHhGlTg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=xMz5531f; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BAE89606EBAC; Fri, 13 Nov 2026 15:58:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=xMz5531f Received: by smtp.kernel.org (Postfix) with ESMTPSA id 695981F000C8; Fri, 13 Nov 2026 15:58:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1794585487; bh=tZ7zrlJ692gL5VeoXOgnpdnv26FxzrS2SiW/5S1BlsU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=xMz5531fEDqPsWSUHDY7i+5q7w+x2BT8xhXCpIhtwCy1tWwrqiuAvYYbWnQps8fak dFgss4bzp5qtEhCl6XXm8xips8na00i8eu8mw8OkKYV2i1IZxiTO/m2XvH9+X1YmX7 EfbClv3XAW3VQsOhyF3Qk15kOHzvYxovmNsiK4iA= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Chris Mason , "Gregory Price (Meta)" , Zi Yan , Balbir Singh , "David Hildenbrand (Arm)" , Sasha Levin Subject: [PATCH 7.3 136/507] mm/shmem: stop retrying folios that cannot be split Date: Fri, 13 Nov 2026 10:47:20 -0500 Message-ID: <20261113153759.061082583@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261113153753.358973689@linuxfoundation.org> References: <20261113153753.358973689@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: stable@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 7.3-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chris Mason [ Upstream commit a842a1f947da8a7020e72f885ffbf2ce6a93685f ] A fault or collapse can insert a large folio crossing EOF after shmem_undo_range() has handled the boundary folios. If splitting that folio fails, truncate_inode_partial_folio() retains it when it is dirty. The final scan then repeatedly finds it because it restarts from an unchanged start. Truncation keeps the inode lock and ignores fatal signals while looping. A concurrent unlink() can then block other directory operations while holding the directory lock and waiting for the file's lock. Advance start past the retained folio, whose truncated part has already been zeroed. Do not move start backwards if the failed split has shrunk the folio. Fix generated by an LLM and sent by Chris Mason in private. Fixes: 55ac8bbe358b ("mm/shmem: fix race in shmem_undo_range w/THP") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Tested-by: Gregory Price (Meta) [ david: split fixes, simplify descriptions, adjust comments ] Reviewed-by: Zi Yan Reviewed-by: Balbir Singh Link: https://patch.msgid.link/20261029-fixes_shmem-v4-7-392fc715d8f6@kernel.org Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Sasha Levin --- mm/shmem.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/mm/shmem.c b/mm/shmem.c index de2362209cc38..249914d48f2ca 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -1275,6 +1275,15 @@ static void shmem_undo_range(struct inode *inode, loff_t lstart, uoff_t lend, index = start; break; } + } else if (folio->mapping) { + /* + * Splitting failed, but the part in the + * range is already zeroed. The folio + * was not dropped, so skip it when + * restarting the scan to avoid retrying + * it forever. + */ + start = max(start, folio_next_index(folio)); } } folio_unlock(folio); -- 2.53.0