Hi David,
On Thu, Feb 26, 2026 at 11:25:24AM +0100, David Hildenbrand (Arm) wrote:
On 2/25/26 17:41, Maxime Ripard wrote:
The CMA dma-buf heap uses cma_alloc() and cma_release() to allocate and free, respectively, its CMA buffers.
However, these functions are not exported. Since we want to turn the CMA heap into a module, let's export them both.
Signed-off-by: Maxime Ripard mripard@kernel.org
mm/cma.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/mm/cma.c b/mm/cma.c index 94b5da468a7d719e5144d33b06bcc7619c0fbcc9..be142b473f3bd41b9c7d8ba4397f018f6993d962 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -949,10 +949,11 @@ struct page *cma_alloc(struct cma *cma, unsigned long count, if (page) set_pages_refcounted(page, count); return page; } +EXPORT_SYMBOL_GPL(cma_alloc); static struct cma_memrange *find_cma_memrange(struct cma *cma, const struct page *pages, unsigned long count) { struct cma_memrange *cmr = NULL; @@ -1025,10 +1026,11 @@ bool cma_release(struct cma *cma, const struct page *pages, __cma_release_frozen(cma, cmr, pages, count); return true; } +EXPORT_SYMBOL_GPL(cma_release); bool cma_release_frozen(struct cma *cma, const struct page *pages, unsigned long count) { struct cma_memrange *cmr;
I'm wondering whether we want to restrict all these exports to the dma-buf module only using EXPORT_SYMBOL_FOR_MODULES().
TIL about EXPORT_SYMBOL_FOR_MODULES, thanks.
Especially dma_contiguous_default_area() (patch #4), I am not sure whether we want arbitrary modules to mess with that.
Yeah, I wasn't too fond about that one either. Alternatively, I guess we could turn dev_get_cma_area into a non-inlined function and export that instead?
Or we could do both.
Maxime
On Thu, Feb 26, 2026 at 2:38 AM Maxime Ripard mripard@kernel.org wrote:
Hi David,
On Thu, Feb 26, 2026 at 11:25:24AM +0100, David Hildenbrand (Arm) wrote:
On 2/25/26 17:41, Maxime Ripard wrote:
The CMA dma-buf heap uses cma_alloc() and cma_release() to allocate and free, respectively, its CMA buffers.
However, these functions are not exported. Since we want to turn the CMA heap into a module, let's export them both.
Signed-off-by: Maxime Ripard mripard@kernel.org
mm/cma.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/mm/cma.c b/mm/cma.c index 94b5da468a7d719e5144d33b06bcc7619c0fbcc9..be142b473f3bd41b9c7d8ba4397f018f6993d962 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -949,10 +949,11 @@ struct page *cma_alloc(struct cma *cma, unsigned long count, if (page) set_pages_refcounted(page, count);
return page;} +EXPORT_SYMBOL_GPL(cma_alloc);
static struct cma_memrange *find_cma_memrange(struct cma *cma, const struct page *pages, unsigned long count) { struct cma_memrange *cmr = NULL; @@ -1025,10 +1026,11 @@ bool cma_release(struct cma *cma, const struct page *pages,
__cma_release_frozen(cma, cmr, pages, count); return true;} +EXPORT_SYMBOL_GPL(cma_release);
bool cma_release_frozen(struct cma *cma, const struct page *pages, unsigned long count) { struct cma_memrange *cmr;
I'm wondering whether we want to restrict all these exports to the dma-buf module only using EXPORT_SYMBOL_FOR_MODULES().
TIL about EXPORT_SYMBOL_FOR_MODULES, thanks.
Ohh, ditto.
Especially dma_contiguous_default_area() (patch #4), I am not sure whether we want arbitrary modules to mess with that.
Yeah, I wasn't too fond about that one either. Alternatively, I guess we could turn dev_get_cma_area into a non-inlined function and export that instead?
I checked the history to see if dev_get_cma_area was converted to inline at some point for performance, but it has always been that way since 3.5. That'd be my only worry with un-inlining and exporting it. EXPORT_SYMBOL_FOR_MODULES sounds like a better way to me.
Or we could do both.
Maxime
On Thu, Feb 26, 2026 at 08:58:51AM -0800, T.J. Mercier wrote:
On Thu, Feb 26, 2026 at 2:38 AM Maxime Ripard mripard@kernel.org wrote:
Hi David,
On Thu, Feb 26, 2026 at 11:25:24AM +0100, David Hildenbrand (Arm) wrote:
On 2/25/26 17:41, Maxime Ripard wrote:
The CMA dma-buf heap uses cma_alloc() and cma_release() to allocate and free, respectively, its CMA buffers.
However, these functions are not exported. Since we want to turn the CMA heap into a module, let's export them both.
Signed-off-by: Maxime Ripard mripard@kernel.org
mm/cma.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/mm/cma.c b/mm/cma.c index 94b5da468a7d719e5144d33b06bcc7619c0fbcc9..be142b473f3bd41b9c7d8ba4397f018f6993d962 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -949,10 +949,11 @@ struct page *cma_alloc(struct cma *cma, unsigned long count, if (page) set_pages_refcounted(page, count);
return page;} +EXPORT_SYMBOL_GPL(cma_alloc);
static struct cma_memrange *find_cma_memrange(struct cma *cma, const struct page *pages, unsigned long count) { struct cma_memrange *cmr = NULL; @@ -1025,10 +1026,11 @@ bool cma_release(struct cma *cma, const struct page *pages,
__cma_release_frozen(cma, cmr, pages, count); return true;} +EXPORT_SYMBOL_GPL(cma_release);
bool cma_release_frozen(struct cma *cma, const struct page *pages, unsigned long count) { struct cma_memrange *cmr;
I'm wondering whether we want to restrict all these exports to the dma-buf module only using EXPORT_SYMBOL_FOR_MODULES().
TIL about EXPORT_SYMBOL_FOR_MODULES, thanks.
Ohh, ditto.
Especially dma_contiguous_default_area() (patch #4), I am not sure whether we want arbitrary modules to mess with that.
Yeah, I wasn't too fond about that one either. Alternatively, I guess we could turn dev_get_cma_area into a non-inlined function and export that instead?
I checked the history to see if dev_get_cma_area was converted to inline at some point for performance, but it has always been that way since 3.5. That'd be my only worry with un-inlining and exporting it. EXPORT_SYMBOL_FOR_MODULES sounds like a better way to me.
I just realised the new tegra heap is also going to use cma_alloc: https://lore.kernel.org/dri-devel/20260122161009.3865888-7-thierry.reding@ke...
I exported dev_get_cma_area() like we discussed, but kept EXPORT_SYMBOL for now in the new version.
Maxime
linaro-mm-sig@lists.linaro.org
-
Maxime Ripard -
T.J. Mercier