Re: [PATCH v3 06/11] mm/cma: Allow dynamically creating CMA areas

[T.J. Mercier]

On Thu, Aug 6, 2026 at 9:21 AM Thierry Reding <thierry.reding@xxxxxxxxxx> wrote:
>
> On Wed, Jul 08, 2026 at 04:49:31PM -0700, T.J. Mercier wrote:
> > On Wed, Jul 1, 2026 at 9:09 AM Thierry Reding <thierry.reding@xxxxxxxxxx> wrote:
> > >
> > > From: Thierry Reding <treding@xxxxxxxxxx>
> > >
> > > There is no technical reason why there should be a limited number of CMA
> > > regions, so extract some code into helpers and use them to create extra
> > > functions (cma_create() and cma_free()) that allow creating and freeing,
> > > respectively, CMA regions dynamically at runtime.
> > >
> > > The static array of CMA areas cannot be replaced by dynamically created
> > > areas because for many of them, allocation must not fail and some cases
> > > may need to initialize them before the slab allocator is even available.
> > > To account for this, keep these "early" areas in a separate list and
> > > track the dynamic areas in a separate list.
>
> Huh... going over this thread again I could've sworn that I had replied
> to this before, but I can't find any evidence of any reply.
>
> > Hi, It looks like you'll also need to update the CMA dma-buf heap's
> > add_cma_heaps init function so that it adds all the CMA areas, not
> > just the early ones.
>
> I would actually rather not do that. The case that we need this for is
> creating a special purpose dma-buf heap that's composed of multiple CMA
> areas. These areas must not be used by anyone else. Exposing these to
> the CMA dma-buf heap would allow anyone to allocate from individual
> chunks and throw off the accounting that we need to do in order to keep
> the protected memory from working correctly.
>
> Besides, given the dynamic nature of this means that the CMA dma-buf
> heap might already have probed when these dynamic CMA areas are added.
> So we would either need to have some way of notifying the CMA dma-buf
> heap of newly created areas or we might end up with an incomplete set
> of registered heaps.
>
> If you really insist, I could look into this, but I think it's actually
> a nice feature that the CMA dma-buf heap only registers these "early"
> areas and exposes them.
>
> Thierry

No problem, thanks for responding. I see there is now discussion about
subdividing a single CMA area for this, and that seems like it could
end up simpler in terms of the CMA code for this series. So I'm
supportive of that idea.