Re: [PATCH v3] dma-contiguous: setup default numa cma area if not configured explicitly

[Feng Tang <feng.tang@linux.alibaba.com>]

On Tue, Apr 28, 2026 at 04:37:08PM +0800, Feng Tang wrote:
> > >  include/linux/cma.h     |  1 +
> > >  kernel/dma/contiguous.c | 14 ++++++++++++--
> > >  mm/cma.c                | 11 ++++++++++-
> > >  3 files changed, 23 insertions(+), 3 deletions(-)
> [...]
> > > +extern int cma_get_nid(const struct cma *cma)
> > > +{
> > > +	return cma->nid;
> > > +}
> > 
> > Why do you have to store the nid instead of just looking it up from the base_pfn
> > in here?
> 
> My thought was 'struct cma' already have 'nid' member, and when CONFIG_NUMA=y,
> it may be useful to save the 'nid' info instead of NUMA_NO_NODE for the default
> cma area (cmdline like cma=XXG@YYG could make it on different node)

One interesting thing is about the API to get nid, I initially worked on
6.19 base, and used 'pfn_to_nid()' which worked well, but I got a kernel
panic when rebasing to 7.1. 

It turned out, latest kernel changed the order of default cma reserving to
before the initialization 'struct page' (only tested on arm64), and
pfn_to_page() will return NULL at the reserving time, so I changed to
early_pfn_to_nid(). Storing the 'nid' could save the logic of chosing the
right API in cma_get_nid().

Thanks,
Feng