From nobody Sun May 24 19:34:49 2026 Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 34AC8331A4B for ; Sat, 23 May 2026 06:01:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.44 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779516098; cv=none; b=fnHl9NNuhrBihlgJ6johCi8i7r8J0GBcb0Uv94d+Inu8M4zA+HCFIouLFYCd239eephBUht/36opbVf+WOanfm77JSrXArZuRAczcLqNOrs9EZJSnSprEXJJ/WjJ1f93CzNLLyQ51WpfYIfr36ZYc+HFCUQzgrRxiPgWxcafL4E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779516098; c=relaxed/simple; bh=Y7Ymyf7qiTxbyZXUgZlO+YnhYDIJGDl/f5myYr0BMMc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=iQUuG9bzzsibzYRFbi5GUu2ohTz3UVuUL88c8bhae/JwKqUH6i0f66wNKKKBrU1hCgHy/hiSmI3Q6iXrtJi2hjoNdQUtFgY93RzJs9VvMgmi9VTRRb+MmI6LSnxpiadISLAF3c4KRFxaNTGlGNhZA1u50Dl28ktteJiMlboj6sc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=dEmddc0A; arc=none smtp.client-ip=209.85.216.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="dEmddc0A" Received: by mail-pj1-f44.google.com with SMTP id 98e67ed59e1d1-367cbac9cb1so7651267a91.3 for ; Fri, 22 May 2026 23:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1779516094; x=1780120894; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=63lvyRs9Tc58HIWr/RdMFYbATzvXY2B5nVbtsmU63VE=; b=dEmddc0AswWYSJPKOZqmxQhXe6GrACWsmgt/aZRuRlasYbtejVuoQZm+dSQ9jQjcc6 C70imSO7H8uHs/MrlomWFIFGCHYCrwn6g22bAZ/GpR0rT7QkBUEz8+jRF77RinRyGTnd 0BVpWcIRVs67Bh3RjlPtUOcIeTytto3TgdMnXTJp2XxwNKTWrtWW00JJs1A7wfInQNJG lmN1/BE6gJkV0uuKpTJqq0XQmVlx8dRscEVJsDDQQ/PdsJAWUEkw4/xpNuqhtuAu4y+O uJAvQEmWUnhGs2pm3/Mn8bYdvTmdAmkibinyn28zKArMUPjLwvIV5sFukuuACGB1ETj2 Rv/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779516094; x=1780120894; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=63lvyRs9Tc58HIWr/RdMFYbATzvXY2B5nVbtsmU63VE=; b=OQydDh6Nj6PihrIAZlYjaxYQaqaA1pQGfqUxGCqBqUb6qYavyJScAQ8hKZYdoSb37x 0G4/g9eQa4PGuJE8fDLnDxubO3xsvKiKc50319vH6VpDekg7o6Gbw8wLXvPWszKORU3H RxvU2K6GBIIKHV5t3XBY17S6UnqecYMCG5OsGxjtmmcdMNBVk3/wf0+h/EGRqRKmNOge PyrXixQZRkTntEbAlo1JVCxOntvKxnHtqTehWeV15u7zNf/bIjb6FMODsM5LiFeWy7Jw KEnfJD3OX7S8hj4Uhe62OI1AECIpZzCCf9KUcxvIxDXg9mEUDgNFkbP1kyAT0wZlbtCV eirA== X-Forwarded-Encrypted: i=1; AFNElJ8QK9ZHXgyNjBIIlV4KkZtkR3MKkCF7YwfdLCzW4XjDAA6J0q2X0ty23+fI3F0x9vcyZiP/FCZa3h2yZFM=@vger.kernel.org X-Gm-Message-State: AOJu0Yz1vsNJU8RwLWTK/OaQKWVMO+QCnqnHMyPSLTFE0/ZYBDG7IEwL HjdKeZMs75dSB9nQUAvd1WVgUTxq3NVguZA18KWIFAkM1P70m8ptnt3ONovc19CMYJE= X-Gm-Gg: Acq92OHr6MHqGBVMfExR+NKm4GPfScawjYm9hPeBx9bdd4OoAI1wb7ctBowNEmoDAJv fR4dsH6LMcnk/bCMBKsF7GnSFAEmTgR2EV+HlixM1zilY9jzTk2So0fzLOk6GOIsF3WZZ5f8mvZ ULHpQsdoSRWMpcSnn7OncZpe2AXmJUotYdOb9UmM8feFMqfcecrt05bFd7r6h7MzVf2wuVUKqS5 ZPhLgHg5yTAfbrrTW4/UkPCUWRsuUd2iV1nuy+EunEAjVlQbkQEMzvSqx3BEv7girYMJ3XBdURi 1UrEGfte2IAg5TVkUwNa9qq+fOj5J7c+ksjgLT3OaOGUIwJdDMqK1ls2h9iexszN4a85THPUDrF lh+WQXKFYK2KBu/ETSAYFdLbUZYIez2MqdJSoiOhr+F7t14bnnt1SFUrCPsLCN/CmirjcOcyOdQ xdL284cuVU1N19hCYXJIHtfy2tk8FaYalA5hzrp6pOahaajrV7H6FJIqc= X-Received: by 2002:a17:90a:fc44:b0:369:bddb:79b5 with SMTP id 98e67ed59e1d1-36a676dc2d0mr6917568a91.2.1779516093645; Fri, 22 May 2026 23:01:33 -0700 (PDT) Received: from n232-176-004.byted.org ([36.110.163.103]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-36a7265a001sm3431127a91.7.2026.05.22.23.01.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 May 2026 23:01:32 -0700 (PDT) From: Muchun Song To: Andrew Morton , David Hildenbrand , linux-mm@kvack.org Cc: Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Frank van der Linden , linux-kernel@vger.kernel.org, stable@vger.kernel.org, Muchun Song , muchun.song@linux.dev Subject: [PATCH v2] mm/cma: fix reserved page leak on activation failure Date: Sat, 23 May 2026 14:01:23 +0800 Message-ID: <20260523060123.2207992-1-songmuchun@bytedance.com> X-Mailer: git-send-email 2.54.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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. Fixes: c009da4258f9 ("mm, cma: support multiple contiguous ranges, if reque= sted") Cc: stable@vger.kernel.org Signed-off-by: Muchun Song --- v1->v2: - fix the failed-range cleanup to avoid using cmr->early_pfn after bitmap_zalloc() failure, as pointed out by Sashiko - explain why the cleanup should still release reserved CMA pages in this __init failure path --- mm/cma.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/mm/cma.c b/mm/cma.c index c7ca567f4c5c..a13ce4999b39 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -188,10 +188,13 @@ static void __init cma_activate_area(struct cma *cma) =20 /* Expose all pages to the buddy, they are useless for CMA. */ if (!test_bit(CMA_RESERVE_PAGES_ON_ERROR, &cma->flags)) { - for (r =3D 0; r < allocrange; r++) { + for (r =3D 0; r < cma->nranges; r++) { + unsigned long start_pfn; + cmr =3D &cma->ranges[r]; + start_pfn =3D r <=3D allocrange ? early_pfn[r] : cmr->early_pfn; end_pfn =3D cmr->base_pfn + cmr->count; - for (pfn =3D early_pfn[r]; pfn < end_pfn; pfn++) + for (pfn =3D start_pfn; pfn < end_pfn; pfn++) free_reserved_page(pfn_to_page(pfn)); } } base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83 --=20 2.54.0