[RFC 1/2] cma: Fix CMA_MIN_ALIGNMENT_BYTES during early_init

[RFC 1/2] cma: Fix CMA_MIN_ALIGNMENT_BYTES during early_init

[Ritesh Harjani (IBM)]

During early init CMA_MIN_ALIGNMENT_BYTES can be PAGE_SIZE,
since pageblock_order is still zero and it gets initialized
later during paging_init() e.g.
paging_init() -> free_area_init() -> set_pageblock_order().

One such use case is -
early_setup() -> early_init_devtree() -> fadump_reserve_mem()

This causes CMA memory alignment check to be bypassed in
cma_init_reserved_mem(). Then later cma_activate_area() can hit
a VM_BUG_ON_PAGE(pfn & ((1 << order) - 1)) if the reserved memory
area was not pageblock_order aligned.

Instead of fixing it locally for fadump case on PowerPC, I believe
this should be fixed for CMA_MIN_ALIGNMENT_BYTES.

<stack trace>
==============
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10010
flags: 0x13ffff800000000(node=1|zone=0|lastcpupid=0x7ffff) CMA
raw: 013ffff800000000 5deadbeef0000100 5deadbeef0000122 0000000000000000
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: VM_BUG_ON_PAGE(pfn & ((1 << order) - 1))
------------[ cut here ]------------
kernel BUG at mm/page_alloc.c:778!

Call Trace:
__free_one_page+0x57c/0x7b0 (unreliable)
free_pcppages_bulk+0x1a8/0x2c8
free_unref_page_commit+0x3d4/0x4e4
free_unref_page+0x458/0x6d0
init_cma_reserved_pageblock+0x114/0x198
cma_init_reserved_areas+0x270/0x3e0
do_one_initcall+0x80/0x2f8
kernel_init_freeable+0x33c/0x530
kernel_init+0x34/0x26c
ret_from_kernel_user_thread+0x14/0x1c

Reported-by: Sachin P Bappalige <sachinpb@linux.ibm.com>
Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
---
 include/linux/cma.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/cma.h b/include/linux/cma.h
index 9db877506ea8..20abc6561bcd 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -5,6 +5,7 @@
 #include <linux/init.h>
 #include <linux/types.h>
 #include <linux/numa.h>
+#include <linux/minmax.h>

 #ifdef CONFIG_CMA_AREAS
 #define MAX_CMA_AREAS	CONFIG_CMA_AREAS
@@ -17,7 +18,8 @@
  * -- can deal with only some pageblocks of a higher-order page being
  *  MIGRATE_CMA, we can use pageblock_nr_pages.
  */
-#define CMA_MIN_ALIGNMENT_PAGES pageblock_nr_pages
+#define CMA_MIN_ALIGNMENT_PAGES \
+	(1ULL << min_not_zero(MAX_PAGE_ORDER, pageblock_order))
 #define CMA_MIN_ALIGNMENT_BYTES (PAGE_SIZE * CMA_MIN_ALIGNMENT_PAGES)

 struct cma;
--
2.46.0

[RFC 2/2] fadump: Make fadump reserve_dump_area_start CMA aligned in case of holes

[Ritesh Harjani (IBM)]

Consider cma alignment into account while calculating base address for
fadump memory allocation. Physical memory ranges can have holes and
fadump_locate_reserve_mem() tries to find a suitable base address.
If CMA is enabled and fadump nocma is false then we need to consider
CMA_MIN_ALIGNMENT_BYTES for reserve_dump_area_start.

For e.g. in case of below memory layout, the most suitable base address
is 0x00000501000000 for crashkernel=4097M which is 16M (order 8) aligned
as expected by CMA_MIN_ALIGNMENT_BYTES on PPC64 during early boot
(when pageblock_order is still not initialized)

~ # cat /proc/iomem
00000000-1fffffff : System RAM
100000000-1ffffffff : System RAM
300000000-3ffffffff : System RAM
500200000-9001fffff : System RAM

~ # dmesg |grep -Ei "fadump|cma"
fadump: Reserved 4112MB of memory at 0x00000501000000 (System RAM: 25088MB)
fadump: Initialized 0x101000000 bytes cma area at 20496MB from 0x1010002a8 bytes of memory reserved for firmware-assisted dump
Kernel command line: root=/dev/vda1 console=ttyS0 nokaslr slub_max_order=0 norandmaps noreboot crashkernel=4097M fadump=on disable_radix=no debug_pagealloc=off
Memory: 21246656K/25690112K available (31872K kernel code, 4544K rwdata, 17280K rodata, 9216K init, 2212K bss, 218432K reserved, 4210688K cma-reserved)

Reported-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
---
 arch/powerpc/kernel/fadump.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index a612e7513a4f..15ea9c80bc03 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -512,6 +512,10 @@ static u64 __init fadump_locate_reserve_mem(u64 base, u64 size)
 	phys_addr_t mstart, mend;
 	int idx = 0;
 	u64 i, ret = 0;
+	unsigned long align = PAGE_SIZE;
+
+	if (IS_ENABLED(CONFIG_CMA) && !fw_dump.nocma)
+		align = CMA_MIN_ALIGNMENT_BYTES;

 	mrngs = reserved_mrange_info.mem_ranges;
 	for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE,
@@ -520,7 +524,7 @@ static u64 __init fadump_locate_reserve_mem(u64 base, u64 size)
 			 i, mstart, mend, base);

 		if (mstart > base)
-			base = PAGE_ALIGN(mstart);
+			base = ALIGN(mstart, align);

 		while ((mend > base) && ((mend - base) >= size)) {
 			if (!overlaps_reserved_ranges(base, base+size, &idx)) {
@@ -529,7 +533,7 @@ static u64 __init fadump_locate_reserve_mem(u64 base, u64 size)
 			}

 			base = mrngs[idx].base + mrngs[idx].size;
-			base = PAGE_ALIGN(base);
+			base = ALIGN(base, align);
 		}
 	}

--
2.46.0

Re: [RFC 1/2] cma: Fix CMA_MIN_ALIGNMENT_BYTES during early_init

[David Hildenbrand]

On 08.10.24 15:27, Ritesh Harjani (IBM) wrote:
> During early init CMA_MIN_ALIGNMENT_BYTES can be PAGE_SIZE,
> since pageblock_order is still zero and it gets initialized
> later during paging_init() e.g.
> paging_init() -> free_area_init() -> set_pageblock_order().
> 
> One such use case is -
> early_setup() -> early_init_devtree() -> fadump_reserve_mem()
> 
> This causes CMA memory alignment check to be bypassed in
> cma_init_reserved_mem(). Then later cma_activate_area() can hit
> a VM_BUG_ON_PAGE(pfn & ((1 << order) - 1)) if the reserved memory
> area was not pageblock_order aligned.
> 
> Instead of fixing it locally for fadump case on PowerPC, I believe
> this should be fixed for CMA_MIN_ALIGNMENT_BYTES.

I think we should add a way to catch the usage of 
CMA_MIN_ALIGNMENT_BYTES before it actually has meaning (before 
pageblock_order was set) and fix the PowerPC usage by reshuffling the 
code accordingly.

-- 
Cheers,

David / dhildenb

Re: [RFC 1/2] cma: Fix CMA_MIN_ALIGNMENT_BYTES during early_init

[Ritesh Harjani]

David Hildenbrand <david@redhat.com> writes:

> On 08.10.24 15:27, Ritesh Harjani (IBM) wrote:
>> During early init CMA_MIN_ALIGNMENT_BYTES can be PAGE_SIZE,
>> since pageblock_order is still zero and it gets initialized
>> later during paging_init() e.g.
>> paging_init() -> free_area_init() -> set_pageblock_order().
>> 
>> One such use case is -
>> early_setup() -> early_init_devtree() -> fadump_reserve_mem()
>> 
>> This causes CMA memory alignment check to be bypassed in
>> cma_init_reserved_mem(). Then later cma_activate_area() can hit
>> a VM_BUG_ON_PAGE(pfn & ((1 << order) - 1)) if the reserved memory
>> area was not pageblock_order aligned.
>> 
>> Instead of fixing it locally for fadump case on PowerPC, I believe
>> this should be fixed for CMA_MIN_ALIGNMENT_BYTES.
>
> I think we should add a way to catch the usage of 
> CMA_MIN_ALIGNMENT_BYTES before it actually has meaning (before 
> pageblock_order was set)

Maybe by enforcing that the pageblock_order should not be zero where we
do the alignment check then?

i.e. in cma_init_reserved_mem() 

diff --git a/mm/cma.c b/mm/cma.c
index 3e9724716bad..36d753e7a0bf 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -182,6 +182,15 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
        if (!size || !memblock_is_region_reserved(base, size))
                return -EINVAL;

+       /*
+        * CMA uses CMA_MIN_ALIGNMENT_BYTES as alignment requirement which
+        * needs pageblock_order to be initialized. Let's enforce it.
+        */
+       if (!pageblock_order) {
+               pr_err("pageblock_order not yet initialized. Called during early boot?\n");
+               return -EINVAL;
+       }
+
        /* ensure minimal alignment required by mm core */
        if (!IS_ALIGNED(base | size, CMA_MIN_ALIGNMENT_BYTES))
                return -EINVAL;


> and fix the PowerPC usage by reshuffling the 
> code accordingly.

Ok. I will submit a v2 with the above patch incldued.

Thanks for the review!
-ritesh