[PATCH 0/2] mm/cma: accept memory of CMA areas reserved with memblock_reserve()

[PATCH 0/2] mm/cma: accept memory of CMA areas reserved with memblock_reserve()

[Mike Rapoport (Microsoft)]

Pages of allocated CMA areas are released to the buddy allocator with
__free_pages(), which does not check for unaccepted memory.

This usually works because memblock accepts the memory it allocates.

However, multi-range CMA areas, used by hugetlb_cma, and fixed CMA areas
requested with cma=<size>@<base> are reserved with memblock_reserve() and
their memory is never accepted.

On TDX and SEV-SNP guests the first access to such a page is fatal.

To ease the backporting, each case is addressed by a separate patch:
- patch 1 accepts the memory of multi-range CMA areas
- patch 2 does the same for the fixed CMA areas

The second patch won't apply cleanly to 6.6 and 6.12, but I believe the
stable team LLMs will take care of that :)

---
Mike Rapoport (Microsoft) (2):
      mm/cma: accept memory of multi-range CMA areas
      mm/cma: accept memory of CMA areas reserved at a fixed address

 mm/cma.c | 4 ++++
 1 file changed, 4 insertions(+)
---
base-commit: 5b0764a53235d3c77e1ed674e836e1b3fe1a4b1f
change-id: 20261029-cma-multi-97fd4e58aa08

--
Sincerely yours,
Mike.

[PATCH 1/2] mm/cma: accept memory of multi-range CMA areas

[Mike Rapoport (Microsoft)]

On systems with unaccepted memory, memblock allocations accept the
allocated range, but when cma_declare_contiguous_multi() uses open coded
allocation of multiple ranges, it reserves them with memblock_reserve()
and they are never accepted.

These pages are released to the buddy allocator by cma_activate_area()
with __free_pages() that does not check for unaccepted memory, so the
first access to such a page in a TDX or SEV-SNP guest is fatal.

Accept the memory of each range when it is reserved.

Fixes: c009da4258f9 ("mm, cma: support multiple contiguous ranges, if requested")
Cc: stable@vger.kernel.org
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
---
 mm/cma.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/cma.c b/mm/cma.c
index a10ea37a261da..0035efb1130a5 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -678,6 +678,8 @@ int __init cma_declare_contiguous_multi(phys_addr_t total_size,
 			break;
 		}
 
+		accept_memory(mlp->base, size);
+
 		pr_debug("created region %d: %016llx - %016llx\n",
 		    nr, (u64)mlp->base, (u64)mlp->base + size);
 		cmrp = &cma->ranges[nr++];

-- 
2.53.0

Re: [PATCH 1/2] mm/cma: accept memory of multi-range CMA areas

[Gupta, Pankaj]

> On systems with unaccepted memory, memblock allocations accept the
> allocated range, but when cma_declare_contiguous_multi() uses open coded
> allocation of multiple ranges, it reserves them with memblock_reserve()
> and they are never accepted.
>
> These pages are released to the buddy allocator by cma_activate_area()
> with __free_pages() that does not check for unaccepted memory, so the
> first access to such a page in a TDX or SEV-SNP guest is fatal.
>
> Accept the memory of each range when it is reserved.

Fix looks correct to me.

Any easy way to reproduce and test on SEV SNP?

Thanks,

Pankaj

>
> Fixes: c009da4258f9 ("mm, cma: support multiple contiguous ranges, if requested")
> Cc: stable@vger.kernel.org
> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
>   mm/cma.c | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/mm/cma.c b/mm/cma.c
> index a10ea37a261da..0035efb1130a5 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -678,6 +678,8 @@ int __init cma_declare_contiguous_multi(phys_addr_t total_size,
>   			break;
>   		}
>   
> +		accept_memory(mlp->base, size);
> +
>   		pr_debug("created region %d: %016llx - %016llx\n",
>   		    nr, (u64)mlp->base, (u64)mlp->base + size);
>   		cmrp = &cma->ranges[nr++];
>

Re: [PATCH 1/2] mm/cma: accept memory of multi-range CMA areas

[Mike Rapoport]

On Thu, Oct 29, 2026 at 11:52:53AM +0100, Gupta, Pankaj wrote:
> 
> > On systems with unaccepted memory, memblock allocations accept the
> > allocated range, but when cma_declare_contiguous_multi() uses open coded
> > allocation of multiple ranges, it reserves them with memblock_reserve()
> > and they are never accepted.
> > 
> > These pages are released to the buddy allocator by cma_activate_area()
> > with __free_pages() that does not check for unaccepted memory, so the
> > first access to such a page in a TDX or SEV-SNP guest is fatal.
> > 
> > Accept the memory of each range when it is reserved.
> 
> Fix looks correct to me.
> 
> Any easy way to reproduce and test on SEV SNP?

I think running a VM with 16G or ram on a single node and with

hugetlb_cma=8G memmap=2M\$0x2ffe00000 init_on_free=1
 
in the kernel command line will do the trick.

> Thanks,
> 
> Pankaj
> 
> > 
> > Fixes: c009da4258f9 ("mm, cma: support multiple contiguous ranges, if requested")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> > ---
> >   mm/cma.c | 2 ++
> >   1 file changed, 2 insertions(+)
> > 
> > diff --git a/mm/cma.c b/mm/cma.c
> > index a10ea37a261da..0035efb1130a5 100644
> > --- a/mm/cma.c
> > +++ b/mm/cma.c
> > @@ -678,6 +678,8 @@ int __init cma_declare_contiguous_multi(phys_addr_t total_size,
> >   			break;
> >   		}
> > +		accept_memory(mlp->base, size);
> > +
> >   		pr_debug("created region %d: %016llx - %016llx\n",
> >   		    nr, (u64)mlp->base, (u64)mlp->base + size);
> >   		cmrp = &cma->ranges[nr++];
> > 

-- 
Sincerely yours,
Mike.

[PATCH 2/2] mm/cma: accept memory of CMA areas reserved at a fixed address

[Mike Rapoport (Microsoft)]

CMA areas allocated from memblock have their memory accepted by
memblock_alloc_range_nid(), but areas reserved at a fixed address with
memblock_reserve() are not.

If a fixed CMA area is requested by the cma=<size>@<base> command line
parameter, it may be in regular RAM and on TDX and SEV-SNP guests it
must be accepted.

Accept the memory of fixed CMA areas as well, so that all CMA areas are
accepted regardless of how they were reserved.

Fixes: 75d090fd167a ("x86/tdx: Add unaccepted memory support")
Cc: stable@vger.kernel.org
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
---
 mm/cma.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/cma.c b/mm/cma.c
index 0035efb1130a5..f61d52796f4ef 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -381,6 +381,8 @@ static int __init cma_fixed_reserve(phys_addr_t base, phys_addr_t size)
 		return -EBUSY;
 	}
 
+	accept_memory(base, size);
+
 	return 0;
 }
 

-- 
2.53.0

Re: [PATCH 0/2] mm/cma: accept memory of CMA areas reserved with memblock_reserve()

[Kiryl Shutsemau]

On Thu, Oct 29, 2026 at 12:18:36PM +0200, Mike Rapoport (Microsoft) wrote:
> Pages of allocated CMA areas are released to the buddy allocator with
> __free_pages(), which does not check for unaccepted memory.
> 
> This usually works because memblock accepts the memory it allocates.
> 
> However, multi-range CMA areas, used by hugetlb_cma, and fixed CMA areas
> requested with cma=<size>@<base> are reserved with memblock_reserve() and
> their memory is never accepted.

It feels like memblock_reserve() abuse, no?

crashkernel=size@base already uses memblock_phys_alloc_range() for this.
Should the fixed and multi-range CMA paths go through the allocation API
as well.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

Re: [PATCH 0/2] mm/cma: accept memory of CMA areas reserved with memblock_reserve()

[Mike Rapoport]

On Thu, Oct 29, 2026 at 12:27:23PM +0000, Kiryl Shutsemau wrote:
> On Thu, Oct 29, 2026 at 12:18:36PM +0200, Mike Rapoport (Microsoft) wrote:
> > Pages of allocated CMA areas are released to the buddy allocator with
> > __free_pages(), which does not check for unaccepted memory.
> > 
> > This usually works because memblock accepts the memory it allocates.
> > 
> > However, multi-range CMA areas, used by hugetlb_cma, and fixed CMA areas
> > requested with cma=<size>@<base> are reserved with memblock_reserve() and
> > their memory is never accepted.
> 
> It feels like memblock_reserve() abuse, no?
> 
> crashkernel=size@base already uses memblock_phys_alloc_range() for this.
> Should the fixed and multi-range CMA paths go through the allocation API
> as well.

Fixed path already has the range, why would it use allocation APIs?

The multi-range could, but it will be several times slower and I believe
the intention was to avoid allocation APIs exactly because of that.

> -- 
>   Kiryl Shutsemau / Kirill A. Shutemov

-- 
Sincerely yours,
Mike.

Re: [PATCH 0/2] mm/cma: accept memory of CMA areas reserved with memblock_reserve()

[Kiryl Shutsemau]

On Thu, Oct 29, 2026 at 02:40:21PM +0200, Mike Rapoport wrote:
> On Thu, Oct 29, 2026 at 12:27:23PM +0000, Kiryl Shutsemau wrote:
> > On Thu, Oct 29, 2026 at 12:18:36PM +0200, Mike Rapoport (Microsoft) wrote:
> > > Pages of allocated CMA areas are released to the buddy allocator with
> > > __free_pages(), which does not check for unaccepted memory.
> > > 
> > > This usually works because memblock accepts the memory it allocates.
> > > 
> > > However, multi-range CMA areas, used by hugetlb_cma, and fixed CMA areas
> > > requested with cma=<size>@<base> are reserved with memblock_reserve() and
> > > their memory is never accepted.
> > 
> > It feels like memblock_reserve() abuse, no?
> > 
> > crashkernel=size@base already uses memblock_phys_alloc_range() for this.
> > Should the fixed and multi-range CMA paths go through the allocation API
> > as well.
> 
> Fixed path already has the range, why would it use allocation APIs?

Having the range doesn't make it a reservation. Both paths take free
memory for the kernel's use, which is an allocation, and an allocation
has to be accepted. memblock_reserve() is for memory that is already in
use: kernel image, initrd, firmware tables. Using it for allocations
leaves acceptance to every caller, and both CMA paths missed it.

If memblock_phys_alloc_range() is the wrong tool, let's add a
memblock_*alloc*() helper that takes the exact range and does the reserve
plus memblock_prep_allocation(), the way memblock_alloc_hugetlb() finishes
its own search. There is no search, so the multi-range path doesn't get
slower, and accept_memory() stays inside memblock.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

Re: [PATCH 0/2] mm/cma: accept memory of CMA areas reserved with memblock_reserve()

[Mike Rapoport]

On Thu, Oct 29, 2026 at 01:17:06PM +0000, Kiryl Shutsemau wrote:
> On Thu, Oct 29, 2026 at 02:40:21PM +0200, Mike Rapoport wrote:
> > On Thu, Oct 29, 2026 at 12:27:23PM +0000, Kiryl Shutsemau wrote:
> > > On Thu, Oct 29, 2026 at 12:18:36PM +0200, Mike Rapoport (Microsoft) wrote:
> > > > Pages of allocated CMA areas are released to the buddy allocator with
> > > > __free_pages(), which does not check for unaccepted memory.
> > > > 
> > > > This usually works because memblock accepts the memory it allocates.
> > > > 
> > > > However, multi-range CMA areas, used by hugetlb_cma, and fixed CMA areas
> > > > requested with cma=<size>@<base> are reserved with memblock_reserve() and
> > > > their memory is never accepted.
> > > 
> > > It feels like memblock_reserve() abuse, no?
> > > 
> > > crashkernel=size@base already uses memblock_phys_alloc_range() for this.
> > > Should the fixed and multi-range CMA paths go through the allocation API
> > > as well.
> > 
> > Fixed path already has the range, why would it use allocation APIs?
> 
> Having the range doesn't make it a reservation. Both paths take free
> memory for the kernel's use, which is an allocation, and an allocation
> has to be accepted. memblock_reserve() is for memory that is already in
> use: kernel image, initrd, firmware tables. Using it for allocations
> leaves acceptance to every caller, and both CMA paths missed it.

memblock_reserve() predates any allocation APIs and it is used to say "I
know this memory is free, I'm taking it". So memory acceptance should have
take it into account.

> If memblock_phys_alloc_range() is the wrong tool, let's add a
> memblock_*alloc*() helper that takes the exact range and does the reserve
> plus memblock_prep_allocation(), the way memblock_alloc_hugetlb() finishes
> its own search. There is no search, so the multi-range path doesn't get
> slower, and accept_memory() stays inside memblock.

A new helper that does reserve and accept makes sense, but let's do it on
top and also audit other callers of memblock_reserve(). I believe we may
also hit some curious corner cases with memmap=, although this is less
likely.

These two are really simple and easily backportable and I don't see an
issue with calling accept_memory in low level cma code.

cma_declare_contiguous_multi() has other issues and I'm reworking it right
now. But again, that does not mean a simple addition of accept_memory to
CMA contradicts it.
 
> -- 
>   Kiryl Shutsemau / Kirill A. Shutemov

-- 
Sincerely yours,
Mike.

Re: [PATCH 0/2] mm/cma: accept memory of CMA areas reserved with memblock_reserve()

[Kiryl Shutsemau]

On Thu, Oct 29, 2026 at 05:03:33PM +0200, Mike Rapoport wrote:
> On Thu, Oct 29, 2026 at 01:17:06PM +0000, Kiryl Shutsemau wrote:
> > On Thu, Oct 29, 2026 at 02:40:21PM +0200, Mike Rapoport wrote:
> > > On Thu, Oct 29, 2026 at 12:27:23PM +0000, Kiryl Shutsemau wrote:
> > > > On Thu, Oct 29, 2026 at 12:18:36PM +0200, Mike Rapoport (Microsoft) wrote:
> > > > > Pages of allocated CMA areas are released to the buddy allocator with
> > > > > __free_pages(), which does not check for unaccepted memory.
> > > > > 
> > > > > This usually works because memblock accepts the memory it allocates.
> > > > > 
> > > > > However, multi-range CMA areas, used by hugetlb_cma, and fixed CMA areas
> > > > > requested with cma=<size>@<base> are reserved with memblock_reserve() and
> > > > > their memory is never accepted.
> > > > 
> > > > It feels like memblock_reserve() abuse, no?
> > > > 
> > > > crashkernel=size@base already uses memblock_phys_alloc_range() for this.
> > > > Should the fixed and multi-range CMA paths go through the allocation API
> > > > as well.
> > > 
> > > Fixed path already has the range, why would it use allocation APIs?
> > 
> > Having the range doesn't make it a reservation. Both paths take free
> > memory for the kernel's use, which is an allocation, and an allocation
> > has to be accepted. memblock_reserve() is for memory that is already in
> > use: kernel image, initrd, firmware tables. Using it for allocations
> > leaves acceptance to every caller, and both CMA paths missed it.
> 
> memblock_reserve() predates any allocation APIs and it is used to say "I
> know this memory is free, I'm taking it". So memory acceptance should have
> take it into account.
> 
> > If memblock_phys_alloc_range() is the wrong tool, let's add a
> > memblock_*alloc*() helper that takes the exact range and does the reserve
> > plus memblock_prep_allocation(), the way memblock_alloc_hugetlb() finishes
> > its own search. There is no search, so the multi-range path doesn't get
> > slower, and accept_memory() stays inside memblock.
> 
> A new helper that does reserve and accept makes sense, but let's do it on
> top and also audit other callers of memblock_reserve().

Fair enough. Feel free to use for this patchset:

Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>

-- 
  Kiryl Shutsemau / Kirill A. Shutemov