From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (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 BCD7F2F7EE8 for ; Mon, 10 Aug 2026 01:09:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=96.67.55.147 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786324147; cv=none; b=V5PiLe1IuxUancYXZ5ngmK5NVBUoUrb0tgJ8AUC+iB9LxuA382SXPjrzHtNlHChU5oAQyHl4esP11DkJfyaXYwuQjUYpTs2yZmCIM8hVt4Rpc61/ZyoQB4e9QO7UEJ5WXQYJKaS5v8PxdJFph++lO7vrT41S1XVVOTbp0OEHtpk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786324147; c=relaxed/simple; bh=FuZZcl7pB6J6izZMedOddAv0ZxzFz8osQQbyhMLWmfM=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type; b=LCIR6EvfuD2oRx58HoNEAicTWChMhMi2f0IuC+l1YL3Y9oG4jHqieWaPHhjEBszhk1FEh6HcuPe4aDrpVmO2dehrhBuu/OT2maAVJ0XD/Dm9TqOky11cXH8wH/LjQJ4SwRImL4PMGbw1oSJh34p2zDtP9owSmVoGokCQpTGL8ac= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com; spf=pass smtp.mailfrom=surriel.com; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b=jH36bWdH; arc=none smtp.client-ip=96.67.55.147 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=surriel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b="jH36bWdH" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=surriel.com ; s=mail; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=0J6vE+M6GXmj6wruBJq705a8UBdBkuRmzd+D8Xhn9KI=; b=jH36bWdHlvCL3AAMg+oKExRRIV ocZON57aM4aKu3Lb/kBaroH7/jHTkLO2QrXg2GQPmemDbMz42qztkvk1SeovSTIA0RE7wi7rBDS82 ufu0mRtlTR3IOUZ/UGnBS2Ui7OsvzOE6iUxOd5GOIkUzRkNYMtw58uanhDEJPjCGnkxWldGYQSyuZ v7V8rua6MGo+wNKa/u9MVyYaNxqtKJM+SFXDuYVmUWyR5eDUt7ijNyG/irp8a4xmEgYZOW+eCL6AV J89qwBsXfxky6fFQx4A9WVFjDT/LGMMFG7Qcmr9F0cYA8nFZHkPcr7rzWIaBn+CEt10cKdtHelwVk QX8vjp2w==; Received: from [2601:18c:8100:a0e0:5a47:caff:fe78:8708] (helo=fangorn) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1wtESu-000000001bM-2QWe; Sun, 09 Aug 2026 21:06:08 -0400 Date: Sun, 9 Aug 2026 21:06:08 -0400 From: Rik van Riel To: Andrew Morton Cc: David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: [RFC PATCH] mm/cma: don't release CMA pages still in use Message-ID: <20260809210608.06b5ccb9@fangorn> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit When a driver calls dma_free_contiguous() before quiescing DMA, the page still has a reference from the device. put_page_testzero() there returns false, ret is incremented, WARN fires, but the code proceeds to free_contig_frozen_range() putting a live page onto buddy and clearing the bitmap. Later cma_alloc() hands the same PFN to a new owner while the original holder still references it. A concurrent put_page() that drops the last reference between the testzero loop and free_contig_frozen_range() can double-queue the page via page->lru, corrupting buddy lists. Fix by freeing already-frozen pages in contiguous runs via __cma_release_frozen(), while skipping still-referenced pages. The CMA address space for pages that are still in use at cma_release() time gets leaked, but the pages themselves will get freed once the user drops the last refcount. This change should be safe because nothing can get reallocated while it is still in use. Fixes: 9bda131c6093 ("mm: cma: add cma_alloc_frozen{_compound}()") Cc: stable@vger.kernel.org Assisted-by: Hermes:muse-spark-1.2 Reported-by: Chris Mason Signed-off-by: Rik van Riel --- mm/cma.c | 36 +++++++++++++++++++++++++++++------- 1 file changed, 29 insertions(+), 7 deletions(-) diff --git a/mm/cma.c b/mm/cma.c index a13ce4999b39..66952bb03abb 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -1018,20 +1018,42 @@ bool cma_release(struct cma *cma, const struct page *pages, unsigned long count) { struct cma_memrange *cmr; - unsigned long ret = 0; + unsigned long skipped = 0; unsigned long i, pfn; + unsigned long base_pfn; + unsigned long run_start = 0; + unsigned long run_len = 0; cmr = find_cma_memrange(cma, pages, count); if (!cmr) return false; - pfn = page_to_pfn(pages); - for (i = 0; i < count; i++, pfn++) - ret += !put_page_testzero(pfn_to_page(pfn)); - - WARN(ret, "%lu pages are still in use!\n", ret); + base_pfn = page_to_pfn(pages); + pfn = base_pfn; + for (i = 0; i < count; i++, pfn++) { + if (put_page_testzero(pfn_to_page(pfn))) { + /* Add it to the batch. */ + if (run_len == 0) + run_start = pfn; + run_len++; + } else { + /* + * This page is still in use! Free the freeable + * pages encountered so far, but skip this page. + */ + if (run_len) { + __cma_release_frozen(cma, cmr, + pfn_to_page(run_start), + run_len); + run_len = 0; + } + skipped++; + } + } + if (run_len) + __cma_release_frozen(cma, cmr, pfn_to_page(run_start), run_len); - __cma_release_frozen(cma, cmr, pages, count); + WARN(skipped, "%lu pages are still in use!\n", skipped); return true; } -- 2.55.0