Re: [PATCH v3] mm/cma: simplify cma_declare_contiguous_multi()

[Mike Rapoport <rppt@kernel.org>]

On Thu, Nov 12, 2026 at 10:38:51PM -0800, Andrew Morton wrote:
> On Thu, 12 Nov 2026 10:16:57 +0200 "Mike Rapoport (Microsoft)" <rppt@kernel.org> wrote:
> 
> > When cma_declare_contiguous_multi() cannot allocate a CMA area as a
> > single range, it falls back to collecting a list of up to CMA_MAX_RANGES
> > largest free ranges above 4G, reserves them in memblock and adds them to
> > cma->ranges.
> > 
> > The list and subsequently cma->ranges are supposed to be sorted in the
> > order of base addresses of the "allocated" ranges.
> > 
> > This implementation has two bugs:
> > 
> > * The allocation may fail even when there is enough free memory because
> >   list_insert_sorted() sorts the list in the wrong order.
> > 
> >   When the list is full, the largest range is evicted rather than the
> >   smallest, the final list is not sorted by address, and the smallest
> >   ranges are used first.
> > 
> > * the function may report success while it reserved less memory than
> >   requested because sizesum accounts for ranges that were skipped.
> > 
> > And overall it is a lot of list management and open coded range
> > selection for no real gain.
> > 
> > Replace the current code with a loop that finds the largest free range
> > above 4G, reserves as much of it as needed and repeats until the entire
> > area is reserved or CMA_MAX_RANGES ranges are used.
> > 
> > After successful alocation sort the cma->ranges by their base address.
> > 
> > The new code scans free memory once for every range rather than once
> > for all ranges, so it is slightly slower, but it is way simpler and more
> > robust.
> 
> Thanks.
> 
> >  mm/cma.c | 269 +++++++++++++++++++--------------------------------------------
> >  1 file changed, 81 insertions(+), 188 deletions(-)
> 
> Win.
> 
> 
> Ivy's 2-patch series
> https://lore.kernel.org/cover.1792032699.git.skunkolee@gmail.com
> carried cc:stable but "No kernel-level reproducer was produced and
> nothing was tested beyond compiling; the examples in the commit
> messages come from a userspace copy of the helper and the selection
> loop, written from the source.".  And my LLM's web trawl couldn't find
> reports of anyone hitting this.
> 
> So I'm thinking next-merge-window, no cc:stable.

Yes, and there will be v4, sigh


-- 
Sincerely yours,
Mike.