Re: [PATCH] dma-contiguous: fix truncation of numa_cma / cma_pernuma sizes >= 2G

On 22.08.2026 00:42, Alexander Graf wrote:
> numa_cma=0:4G reserves nothing at all. dma_numa_cma_reserve() copies the
> requested size into a local int before handing it to
> cma_declare_contiguous_nid(), so 0x100000000 truncates to zero and the
> loop skips the node silently. Both parameters are documented in
> kernel-parameters.txt as nn[MG], so that is the syntax the documentation
> invites.
>
> Which bits survive decides what a request turns into: 4G, 8G and 16G
> reserve nothing, 2G, 3G and 6G sign-extend into a size the allocator
> rejects with a warning, and 5G quietly reserves 1G.
>
> It reaches further than those parameters. On a CMA_SIZE_PERNUMA kernel
> with no per-node parameter, dma_numa_cma_reserve() takes the per-node
> size from the default area, so a plain cma=4G on a multi-node machine
> feeds that size through the same local and loses every per-node area.
>
> numa_cma_size[] and pernuma_size_bytes are both phys_addr_t, so use it
> for the local too, and give early_numa_cma() separate variables for the
> node id and the size while in there.
>
> Fixes: d5cae2261b86 ("dma-contiguous: simplify numa cma area handling")
> Cc: [email protected]
> Assisted-by: Kiro:claude-opus-5
> Signed-off-by: Alexander Graf <[email protected]>

Applied to dma-mapping-for-next. Thanks!

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland