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

[Kiryl Shutsemau <kas@kernel.org>]

On Thu, Oct 29, 2026 at 05:03:33PM +0200, Mike Rapoport wrote:
> 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().

Fair enough. Feel free to use for this patchset:

Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>

-- 
  Kiryl Shutsemau / Kirill A. Shutemov