Re: [PATCH 0/2] mm/cma: accept memory of CMA areas reserved with memblock_reserve()

[Mike Rapoport]

On Thu, Oct 29, 2026 at 01:17:06PM +0000, Kiryl Shutsemau wrote:
> On Thu, Oct 29, 2026 at 02:40:21PM +0200, Mike Rapoport wrote:
> > On Thu, Oct 29, 2026 at 12:27:23PM +0000, Kiryl Shutsemau wrote:
> > > On Thu, Oct 29, 2026 at 12:18:36PM +0200, Mike Rapoport (Microsoft) wrote:
> > > > Pages of allocated CMA areas are released to the buddy allocator with
> > > > __free_pages(), which does not check for unaccepted memory.
> > > > 
> > > > This usually works because memblock accepts the memory it allocates.
> > > > 
> > > > However, multi-range CMA areas, used by hugetlb_cma, and fixed CMA areas
> > > > requested with cma=<size>@<base> are reserved with memblock_reserve() and
> > > > their memory is never accepted.
> > > 
> > > It feels like memblock_reserve() abuse, no?
> > > 
> > > crashkernel=size@base already uses memblock_phys_alloc_range() for this.
> > > Should the fixed and multi-range CMA paths go through the allocation API
> > > as well.
> > 
> > Fixed path already has the range, why would it use allocation APIs?
> 
> Having the range doesn't make it a reservation. Both paths take free
> memory for the kernel's use, which is an allocation, and an allocation
> has to be accepted. memblock_reserve() is for memory that is already in
> use: kernel image, initrd, firmware tables. Using it for allocations
> leaves acceptance to every caller, and both CMA paths missed it.

memblock_reserve() predates any allocation APIs and it is used to say "I
know this memory is free, I'm taking it". So memory acceptance should have
take it into account.

> If memblock_phys_alloc_range() is the wrong tool, let's add a
> memblock_*alloc*() helper that takes the exact range and does the reserve
> plus memblock_prep_allocation(), the way memblock_alloc_hugetlb() finishes
> its own search. There is no search, so the multi-range path doesn't get
> slower, and accept_memory() stays inside memblock.

A new helper that does reserve and accept makes sense, but let's do it on
top and also audit other callers of memblock_reserve(). I believe we may
also hit some curious corner cases with memmap=, although this is less
likely.

These two are really simple and easily backportable and I don't see an
issue with calling accept_memory in low level cma code.

cma_declare_contiguous_multi() has other issues and I'm reworking it right
now. But again, that does not mean a simple addition of accept_memory to
CMA contradicts it.
 
> -- 
>   Kiryl Shutsemau / Kirill A. Shutemov

-- 
Sincerely yours,
Mike.