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

--4gmnekg7ar3gl7m6
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PATCH v3 06/11] mm/cma: Allow dynamically creating CMA areas
MIME-Version: 1.0

On Wed, Jul 08, 2026 at 04:49:31PM -0700, T.J. Mercier wrote:
> On Wed, Jul 1, 2026 at 9:09=E2=80=AFAM Thierry Reding <thierry.reding@ker=
nel.org> 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

--4gmnekg7ar3gl7m6
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmp0tJQACgkQ3SOs138+
s6Hx2A/+LyXBkYE0i4vOlsqA/Ydjj8c8/300xmhsRpFbwbpF3gTAquepUhv4ccLk
pn6s3oOPckjHUjgqi17LCjM+dbGIQRiXZ5sHHuq69DOmSq6K43pvPWC9DQE3kICK
i05UEwUTy2GyHSp229X6bMmMKYyl4WW9pde+bHXFO3IBdszOFd76qxdMqtl3agOv
kfgnaTJezzmgsC1qP4etPKCdwHkxCcCO+r/IUp5vm8tuot9r3ZmBeyeLcSaboN0D
RP21XS13WS+QLN/rZAXyBAVhrpNrTBOcQcI5CYrTXnDFkJYeQJEkd5ugPi/q2wr4
KM8oHddCYYYHQyIEOG7pFcNGhonqPopbSVLN/BwII0fbmJXppQrdPyR4B3ZzsZzI
51eP67NZSMCtnEqOeaqKYc629FRTyBsrMWfEhmHu19hAJb/p9PvkqxCIR+TlebSt
HbuYY8JUEbz4Ck0Cb9FHGHsuYwsYkSKVpy0CpXnqkYEayTLU7dEHHpoKyTtS5Wvz
w8fNZPuvXMWffnb1L+4nblBj2VNkJCSUvr3ZcgU0H6PlqcES02A5W6ectwCN/2R2
STUcZd3vK2dFxCKRPHOx5+YyienQ9dBUapH7HwK01V0SFwh9m58TpMKmacD+y7vU
Ns4RBrD6r3h3Ua+YybzB1+b9dqB8U4mzDp9x92jAksifc9ZHH5Y=
=/fYh
-----END PGP SIGNATURE-----

--4gmnekg7ar3gl7m6--