On Thu, Aug 6, 2026 at 9:21 AM Thierry Reding <[email protected]> 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 <[email protected]> > > wrote: > > > > > > From: Thierry Reding <[email protected]> > > > > > > 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.
