Re: [PATCH v7 02/22] dma-pool: fix page leak in atomic_pool_expand() cleanup

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Medium] Pages allocated from CMA are incorrectly freed using `__free_pages()` instead of `dma_release_from_contiguous()`, permanently leaking CMA tracking capacity.
--

commit ede353d82bd6f31cd894661b3fa06b014104f3cc
Author: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>

dma-pool: fix page leak in atomic_pool_expand() cleanup
    
atomic_pool_expand() frees the allocated pages from the remove_mapping
error path only when CONFIG_DMA_DIRECT_REMAP is enabled. This patch ensures
the pages are always freed on failure paths by moving the __free_pages() call
outside the CONFIG_DMA_DIRECT_REMAP block.

> diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
> index 2b2fbb7092429..b0303efbc1532 100644
> --- a/kernel/dma/pool.c
> +++ b/kernel/dma/pool.c

[ ... ]

> @@ -130,14 +133,15 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
>  				   1 << order);
>  	if (WARN_ON_ONCE(ret)) {
>  		/* Decrypt succeeded but encrypt failed, purposely leak */
> -		goto out;
> +		leak_pages = true;
>  	}
>  remove_mapping:
>  #ifdef CONFIG_DMA_DIRECT_REMAP
>  	dma_common_free_remap(addr, pool_size);
>  free_page:
> -	__free_pages(page, order);
>  #endif
> +	if (!leak_pages)
> +		__free_pages(page, order);
                ^^^^^^^^^^^^^^^^^^^^^^^^^
[Severity: Medium]
This is a pre-existing issue, but does this cleanup path correctly handle
pages allocated from CMA?

Looking at the allocation logic earlier in atomic_pool_expand():

	do {
		pool_size = 1 << (PAGE_SHIFT + order);
		if (cma_in_zone(gfp))
			page = dma_alloc_from_contiguous(NULL, 1 << order,
							 order, false);
		if (!page)
			page = alloc_pages(gfp | __GFP_NOWARN, order);
	} while (!page && order-- > 0);

If the page was allocated via dma_alloc_from_contiguous(), freeing it
directly with __free_pages() bypasses the CMA bitmap cleanup. This returns
the page to the buddy allocator but permanently reduces the memory available
for contiguous allocations.

Should this instead check if the page came from CMA and call
dma_release_from_contiguous() accordingly?

>  out:
>  	return ret;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701054926.825925-1-aneesh.kumar@kernel.org?part=2