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

[Kiryl Shutsemau]

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.

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.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov