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@kernel.org> wrote:
> >
> > From: Thierry Reding <treding@nvidia.com>
> >
> > 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