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 7171944CF52; Tue, 16 Jun 2026 15:41:03 +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=1781624464; cv=none; b=FAR0w9st/WoIg6vNv7h/Ky6opb2YFEV2FdhS59EP0aITxOkUmUhe/oQ2JdsmLCahy231kcNb6DkR9gHaU4kXjIx28wBphI7zqB2kTE3ro/uNE5Is8dOOPdyXMeBlv+n/aevJKpmDLv2V7Qlq8sYmMyM7T/wSlru7q7X6DXFY4D8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781624464; c=relaxed/simple; bh=MZ3fmhY49bYU0yzHs8+QFgCeemb6jW7vby5t3Oa4Q1A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pxe9JerQxmMse10hCFU6W5itPDBtQzaXpLXNQkasBfcx94VsiFG0g8Pf4WcDLQyxfK7uGFwFfhlURx+8x7WnBhLV0sdeYQaeuQ5qK4r6rYK+qeSq//0ztO1UxcIBO8FzKXI8iRFHKi+KZgEOjJxzhpMANW5k0C9ts1zkqgKp9Fk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=N/tcLUvk; 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="N/tcLUvk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 778561F000E9; Tue, 16 Jun 2026 15:41:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1781624463; bh=2zmgfyOM27uaon5bi3Kv68sJt57HZizZ/4GwdTfCBE8=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=N/tcLUvkJxkRsDODstrzjCQhQjrESC6ZG+KhCGNuUFTYSMbGSJwkiuIWuekYCzH4i ablcUqtETTOH65WYzrJK/CRDoFuG5eMtz1HcU5znjOL+ouadtrkJjF5LRPiO8ZLElh uctx4Wj4WzPH7A2c4WTqT4uXW1gg79C3pmGSZ/q8= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Muchun Song , "Oscar Salvador (SUSE)" , Usama Arif , David Hildenbrand , Frank van der Linden , "Liam R. Howlett" , Lorenzo Stoakes , Michal Hocko , Mike Rapoport , Suren Baghdasaryan , Vlastimil Babka , Andrew Morton Subject: [PATCH 7.0 298/378] mm/cma: fix reserved page leak on activation failure Date: Tue, 16 Jun 2026 20:28:49 +0530 Message-ID: <20260616145125.748257933@linuxfoundation.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260616145109.744539446@linuxfoundation.org> References: <20260616145109.744539446@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 7.0-stable review patch. If anyone has any objections, please let me know. ------------------ From: Muchun Song commit 00739e4dd46dde2b39dd9dd19a27e3c8af4ca0d0 upstream. If cma_activate_area() fails after allocating only part of the range bitmaps, the cleanup path still has to release the reserved pages when CMA_RESERVE_PAGES_ON_ERROR is clear. That is still worth doing even in this __init path. A bitmap_zalloc() failure does not necessarily mean the system cannot make further progress: freeing the reserved CMA pages can return a substantial amount of memory to the buddy allocator and may relieve the temporary memory shortage that caused the allocation failure in the first place. However, the cleanup path currently uses the bitmap-freeing bound for page release as well. That is only correct for ranges whose bitmap allocation already succeeded. The failed range and all later ranges still keep their reserved pages, so a partial bitmap allocation failure can permanently leak them. Fix this by releasing reserved pages for all ranges. Use the saved early_pfn[] value for ranges whose bitmap allocation already succeeded and for the failed range, and use cmr->early_pfn for later ranges whose bitmap allocation was never attempted. Link: https://lore.kernel.org/20260523060123.2207992-1-songmuchun@bytedance.com Fixes: c009da4258f9 ("mm, cma: support multiple contiguous ranges, if requested") Signed-off-by: Muchun Song Reviewed-by: Oscar Salvador (SUSE) Acked-by: Usama Arif Cc: David Hildenbrand Cc: Frank van der Linden Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- mm/cma.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/mm/cma.c +++ b/mm/cma.c @@ -187,10 +187,13 @@ cleanup: /* Expose all pages to the buddy, they are useless for CMA. */ if (!test_bit(CMA_RESERVE_PAGES_ON_ERROR, &cma->flags)) { - for (r = 0; r < allocrange; r++) { + for (r = 0; r < cma->nranges; r++) { + unsigned long start_pfn; + cmr = &cma->ranges[r]; + start_pfn = r <= allocrange ? early_pfn[r] : cmr->early_pfn; end_pfn = cmr->base_pfn + cmr->count; - for (pfn = early_pfn[r]; pfn < end_pfn; pfn++) + for (pfn = start_pfn; pfn < end_pfn; pfn++) free_reserved_page(pfn_to_page(pfn)); } }