[PATCH v2 0/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[PATCH v2 0/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Mike Rapoport]

Hi,

These patches switch m68k boot time memory allocators from bootmem to
memblock + no_bootmem.

The first two patches update __ffs() and __va() definitions to be inline
with other arches and asm-generic. This is required to avoid compilation
warnings in mm/memblock.c and mm/nobootmem.c.

The third patch performs the actual switch of the boot time mm. Its
changelog has detailed description of the changes.

I've tested the !MMU version with qemu-system-m68k -M mcf5208evb
and the MMU version with q800 using qemu from [1].

I've also build tested allyesconfig and *_defconfig.

[1] https://github.com/vivier/qemu-m68k.git

v2:
* fix reservation of the kernel text/data/bss for ColdFire MMU

Mike Rapoport (3):
  m68k/bitops: convert __ffs to match generic declaration
  m68k/page_no.h: force __va argument to be unsigned long
  m68k: switch to MEMBLOCK + NO_BOOTMEM

 arch/m68k/Kconfig               |  3 +++
 arch/m68k/include/asm/bitops.h  |  8 ++++++--
 arch/m68k/include/asm/page_no.h |  2 +-
 arch/m68k/kernel/setup_mm.c     | 14 ++++----------
 arch/m68k/kernel/setup_no.c     | 20 ++++----------------
 arch/m68k/mm/init.c             |  1 -
 arch/m68k/mm/mcfmmu.c           | 13 +++++++------
 arch/m68k/mm/motorola.c         | 35 +++++++++++------------------------
 arch/m68k/sun3/config.c         |  4 ----
 9 files changed, 36 insertions(+), 64 deletions(-)

-- 
2.7.4

[PATCH v2 1/3] m68k/bitops: convert __ffs to match generic declaration

[Mike Rapoport]

The generic bitops declare __ffs as

	static inline unsigned long __ffs(unsigned long word);

Convert the m68k version to match the generic declaration.

Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
---
 arch/m68k/include/asm/bitops.h | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/include/asm/bitops.h b/arch/m68k/include/asm/bitops.h
index 93b47b1..54009ea 100644
--- a/arch/m68k/include/asm/bitops.h
+++ b/arch/m68k/include/asm/bitops.h
@@ -454,7 +454,7 @@ static inline unsigned long ffz(unsigned long word)
  */
 #if (defined(__mcfisaaplus__) || defined(__mcfisac__)) && \
 	!defined(CONFIG_M68000) && !defined(CONFIG_MCPU32)
-static inline int __ffs(int x)
+static inline unsigned long __ffs(unsigned long x)
 {
 	__asm__ __volatile__ ("bitrev %0; ff1 %0"
 		: "=d" (x)
@@ -493,7 +493,11 @@ static inline int ffs(int x)
 		: "dm" (x & -x));
 	return 32 - cnt;
 }
-#define __ffs(x) (ffs(x) - 1)
+
+static inline unsigned long __ffs(unsigned long x)
+{
+	return ffs(x) - 1;
+}
 
 /*
  *	fls: find last bit set.
-- 
2.7.4

[PATCH v2 2/3] m68k/page_no.h: force __va argument to be unsigned long

[Mike Rapoport]

Add explicit casting to unsigned long to the __va() parameter

Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
---
 arch/m68k/include/asm/page_no.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/m68k/include/asm/page_no.h b/arch/m68k/include/asm/page_no.h
index e644c4d..6bbe520 100644
--- a/arch/m68k/include/asm/page_no.h
+++ b/arch/m68k/include/asm/page_no.h
@@ -18,7 +18,7 @@ extern unsigned long memory_end;
 #define __HAVE_ARCH_ALLOC_ZEROED_USER_HIGHPAGE
 
 #define __pa(vaddr)		((unsigned long)(vaddr))
-#define __va(paddr)		((void *)(paddr))
+#define __va(paddr)		((void *)((unsigned long)(paddr)))
 
 #define virt_to_pfn(kaddr)	(__pa(kaddr) >> PAGE_SHIFT)
 #define pfn_to_virt(pfn)	__va((pfn) << PAGE_SHIFT)
-- 
2.7.4

[PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Mike Rapoport]

In m68k the physical memory is described by [memory_start, memory_end] for
!MMU variant and by m68k_memory array of memory ranges for the MMU version.
This information is directly use to register the physical memory with
memblock.

The reserve_bootmem() calls are replaced with memblock_reserve() and the
bootmap bitmap allocation is simply dropped.

Since the MMU variant creates early mappings only for the small part of the
memory we force bottom-up allocations in memblock.

Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
---
 arch/m68k/Kconfig           |  3 +++
 arch/m68k/kernel/setup_mm.c | 14 ++++----------
 arch/m68k/kernel/setup_no.c | 20 ++++----------------
 arch/m68k/mm/init.c         |  1 -
 arch/m68k/mm/mcfmmu.c       | 13 +++++++------
 arch/m68k/mm/motorola.c     | 35 +++++++++++------------------------
 arch/m68k/sun3/config.c     |  4 ----
 7 files changed, 29 insertions(+), 61 deletions(-)

diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 785612b..bd7f38a 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -24,6 +24,9 @@ config M68K
 	select MODULES_USE_ELF_RELA
 	select OLD_SIGSUSPEND3
 	select OLD_SIGACTION
+	select HAVE_MEMBLOCK
+	select ARCH_DISCARD_MEMBLOCK
+	select NO_BOOTMEM
 
 config CPU_BIG_ENDIAN
 	def_bool y
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index f35e3eb..6512955 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -21,6 +21,7 @@
 #include <linux/string.h>
 #include <linux/init.h>
 #include <linux/bootmem.h>
+#include <linux/memblock.h>
 #include <linux/proc_fs.h>
 #include <linux/seq_file.h>
 #include <linux/module.h>
@@ -165,6 +166,8 @@ static void __init m68k_parse_bootinfo(const struct bi_record *record)
 					be32_to_cpu(m->addr);
 				m68k_memory[m68k_num_memory].size =
 					be32_to_cpu(m->size);
+				memblock_add(m68k_memory[m68k_num_memory].addr,
+					     m68k_memory[m68k_num_memory].size);
 				m68k_num_memory++;
 			} else
 				pr_warn("%s: too many memory chunks\n",
@@ -224,10 +227,6 @@ static void __init m68k_parse_bootinfo(const struct bi_record *record)
 
 void __init setup_arch(char **cmdline_p)
 {
-#ifndef CONFIG_SUN3
-	int i;
-#endif
-
 	/* The bootinfo is located right after the kernel */
 	if (!CPU_IS_COLDFIRE)
 		m68k_parse_bootinfo((const struct bi_record *)_end);
@@ -356,14 +355,9 @@ void __init setup_arch(char **cmdline_p)
 #endif
 
 #ifndef CONFIG_SUN3
-	for (i = 1; i < m68k_num_memory; i++)
-		free_bootmem_node(NODE_DATA(i), m68k_memory[i].addr,
-				  m68k_memory[i].size);
 #ifdef CONFIG_BLK_DEV_INITRD
 	if (m68k_ramdisk.size) {
-		reserve_bootmem_node(__virt_to_node(phys_to_virt(m68k_ramdisk.addr)),
-				     m68k_ramdisk.addr, m68k_ramdisk.size,
-				     BOOTMEM_DEFAULT);
+		memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size);
 		initrd_start = (unsigned long)phys_to_virt(m68k_ramdisk.addr);
 		initrd_end = initrd_start + m68k_ramdisk.size;
 		pr_info("initrd: %08lx - %08lx\n", initrd_start, initrd_end);
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index a98af10..3e8d87a 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -28,6 +28,7 @@
 #include <linux/errno.h>
 #include <linux/string.h>
 #include <linux/bootmem.h>
+#include <linux/memblock.h>
 #include <linux/seq_file.h>
 #include <linux/init.h>
 #include <linux/initrd.h>
@@ -86,8 +87,6 @@ void (*mach_power_off)(void);
 
 void __init setup_arch(char **cmdline_p)
 {
-	int bootmap_size;
-
 	memory_start = PAGE_ALIGN(_ramstart);
 	memory_end = _ramend;
 
@@ -142,6 +141,8 @@ void __init setup_arch(char **cmdline_p)
 	pr_debug("MEMORY -> ROMFS=0x%p-0x%06lx MEM=0x%06lx-0x%06lx\n ",
 		 __bss_stop, memory_start, memory_start, memory_end);
 
+	memblock_add(memory_start, memory_end - memory_start);
+
 	/* Keep a copy of command line */
 	*cmdline_p = &command_line[0];
 	memcpy(boot_command_line, command_line, COMMAND_LINE_SIZE);
@@ -158,23 +159,10 @@ void __init setup_arch(char **cmdline_p)
 	min_low_pfn = PFN_DOWN(memory_start);
 	max_pfn = max_low_pfn = PFN_DOWN(memory_end);
 
-	bootmap_size = init_bootmem_node(
-			NODE_DATA(0),
-			min_low_pfn,		/* map goes here */
-			PFN_DOWN(PAGE_OFFSET),
-			max_pfn);
-	/*
-	 * Free the usable memory, we have to make sure we do not free
-	 * the bootmem bitmap so we then reserve it after freeing it :-)
-	 */
-	free_bootmem(memory_start, memory_end - memory_start);
-	reserve_bootmem(memory_start, bootmap_size, BOOTMEM_DEFAULT);
-
 #if defined(CONFIG_UBOOT) && defined(CONFIG_BLK_DEV_INITRD)
 	if ((initrd_start > 0) && (initrd_start < initrd_end) &&
 			(initrd_end < memory_end))
-		reserve_bootmem(initrd_start, initrd_end - initrd_start,
-				 BOOTMEM_DEFAULT);
+		memblock_reserve(initrd_start, initrd_end - initrd_start);
 #endif /* if defined(CONFIG_BLK_DEV_INITRD) */
 
 	/*
diff --git a/arch/m68k/mm/init.c b/arch/m68k/mm/init.c
index 8827b7f..38e2b27 100644
--- a/arch/m68k/mm/init.c
+++ b/arch/m68k/mm/init.c
@@ -71,7 +71,6 @@ void __init m68k_setup_node(int node)
 		pg_data_table[i] = pg_data_map + node;
 	}
 #endif
-	pg_data_map[node].bdata = bootmem_node_data + node;
 	node_set_online(node);
 }
 
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index 2925d79..70dde04 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -14,6 +14,7 @@
 #include <linux/init.h>
 #include <linux/string.h>
 #include <linux/bootmem.h>
+#include <linux/memblock.h>
 
 #include <asm/setup.h>
 #include <asm/page.h>
@@ -153,31 +154,31 @@ int cf_tlb_miss(struct pt_regs *regs, int write, int dtlb, int extension_word)
 
 void __init cf_bootmem_alloc(void)
 {
-	unsigned long start_pfn;
 	unsigned long memstart;
 
 	/* _rambase and _ramend will be naturally page aligned */
 	m68k_memory[0].addr = _rambase;
 	m68k_memory[0].size = _ramend - _rambase;
 
+	memblock_add(m68k_memory[0].addr, m68k_memory[0].size);
+
 	/* compute total pages in system */
 	num_pages = PFN_DOWN(_ramend - _rambase);
 
 	/* page numbers */
 	memstart = PAGE_ALIGN(_ramstart);
 	min_low_pfn = PFN_DOWN(_rambase);
-	start_pfn = PFN_DOWN(memstart);
 	max_pfn = max_low_pfn = PFN_DOWN(_ramend);
 	high_memory = (void *)_ramend;
 
+	/* Reserve kernel text/data/bss */
+	memblock_reserve(memstart, memstart - _rambase);
+
 	m68k_virt_to_node_shift = fls(_ramend - 1) - 6;
 	module_fixup(NULL, __start_fixup, __stop_fixup);
 
-	/* setup bootmem data */
+	/* setup node data */
 	m68k_setup_node(0);
-	memstart += init_bootmem_node(NODE_DATA(0), start_pfn,
-		min_low_pfn, max_low_pfn);
-	free_bootmem_node(NODE_DATA(0), memstart, _ramend - memstart);
 }
 
 /*
diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
index e490ecc..4e17ecb 100644
--- a/arch/m68k/mm/motorola.c
+++ b/arch/m68k/mm/motorola.c
@@ -19,6 +19,7 @@
 #include <linux/types.h>
 #include <linux/init.h>
 #include <linux/bootmem.h>
+#include <linux/memblock.h>
 #include <linux/gfp.h>
 
 #include <asm/setup.h>
@@ -208,7 +209,7 @@ void __init paging_init(void)
 {
 	unsigned long zones_size[MAX_NR_ZONES] = { 0, };
 	unsigned long min_addr, max_addr;
-	unsigned long addr, size, end;
+	unsigned long addr;
 	int i;
 
 #ifdef DEBUG
@@ -253,34 +254,20 @@ void __init paging_init(void)
 	min_low_pfn = availmem >> PAGE_SHIFT;
 	max_pfn = max_low_pfn = max_addr >> PAGE_SHIFT;
 
-	for (i = 0; i < m68k_num_memory; i++) {
-		addr = m68k_memory[i].addr;
-		end = addr + m68k_memory[i].size;
-		m68k_setup_node(i);
-		availmem = PAGE_ALIGN(availmem);
-		availmem += init_bootmem_node(NODE_DATA(i),
-					      availmem >> PAGE_SHIFT,
-					      addr >> PAGE_SHIFT,
-					      end >> PAGE_SHIFT);
-	}
+	/* Reserve kernel text/data/bss and the memory allocated in head.S */
+	memblock_reserve(m68k_memory[0].addr, availmem - m68k_memory[0].addr);
 
 	/*
 	 * Map the physical memory available into the kernel virtual
-	 * address space. First initialize the bootmem allocator with
-	 * the memory we already mapped, so map_node() has something
-	 * to allocate.
+	 * address space. Make sure memblock will not try to allocate
+	 * pages beyond the memory we already mapped in head.S
 	 */
-	addr = m68k_memory[0].addr;
-	size = m68k_memory[0].size;
-	free_bootmem_node(NODE_DATA(0), availmem,
-			  min(m68k_init_mapped_size, size) - (availmem - addr));
-	map_node(0);
-	if (size > m68k_init_mapped_size)
-		free_bootmem_node(NODE_DATA(0), addr + m68k_init_mapped_size,
-				  size - m68k_init_mapped_size);
-
-	for (i = 1; i < m68k_num_memory; i++)
+	memblock_set_bottom_up(true);
+
+	for (i = 0; i < m68k_num_memory; i++) {
+		m68k_setup_node(i);
 		map_node(i);
+	}
 
 	flush_tlb_all();
 
diff --git a/arch/m68k/sun3/config.c b/arch/m68k/sun3/config.c
index 1d28d38..79a2bb8 100644
--- a/arch/m68k/sun3/config.c
+++ b/arch/m68k/sun3/config.c
@@ -123,10 +123,6 @@ static void __init sun3_bootmem_alloc(unsigned long memory_start,
 	availmem = memory_start;
 
 	m68k_setup_node(0);
-	availmem += init_bootmem(start_page, num_pages);
-	availmem = (availmem + (PAGE_SIZE-1)) & PAGE_MASK;
-
-	free_bootmem(__pa(availmem), memory_end - (availmem));
 }
 
 
-- 
2.7.4

Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Geert Uytterhoeven]

Hi Mike,

On Wed, Jul 4, 2018 at 8:28 AM Mike Rapoport <rppt@linux.vnet.ibm.com> wrote:
> In m68k the physical memory is described by [memory_start, memory_end] for
> !MMU variant and by m68k_memory array of memory ranges for the MMU version.
> This information is directly use to register the physical memory with
> memblock.
>
> The reserve_bootmem() calls are replaced with memblock_reserve() and the
> bootmap bitmap allocation is simply dropped.
>
> Since the MMU variant creates early mappings only for the small part of the
> memory we force bottom-up allocations in memblock.
>
> Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>

Thanks a lot for doing this!

My virtual Atari (using ARAnyM) now has +12KiB of memory available:

-Memory: 267976K/276480K available (3037K kernel code, 304K rwdata,
792K rodata, 148K init, 168K bss, 8504K reserved, 0K cma-reserved)
+Memory: 267988K/276480K available (3036K kernel code, 304K rwdata,
792K rodata, 152K init, 168K bss, 8492K reserved, 0K cma-reserved)

However, a WARNING is triggered. With memblock_debug=1:

Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC DSP56K
SCC ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED
memblock_reserve: [0x00000000-0x00439fff] paging_init+0x172/0x462
memblock_reserve: [0x0043a000-0x0043afff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0043b000-0x0043bfff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0043c000-0x0043cfff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0043d000-0x0043dfff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0043e000-0x0043efff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0043f000-0x0043ffff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00440000-0x00440fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00441000-0x00441fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00442000-0x00442fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00443000-0x00443fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00444000-0x00444fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00445000-0x00445fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00446000-0x00446fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00447000-0x00447fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00448000-0x00448fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00449000-0x00449fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0044a000-0x0044afff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0044b000-0x0044bfff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0044c000-0x0044cfff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0044d000-0x0044dfff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0044e000-0x0044efff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0044f000-0x0044ffff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00450000-0x00450fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00451000-0x00451fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00452000-0x00452fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00453000-0x00453fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00454000-0x00454fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00455000-0x00455fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00456000-0x00456fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00457000-0x00457fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00458000-0x00458fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00459000-0x00459fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0045a000-0x0045afff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0045b000-0x0045bfff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0045c000-0x0045cfff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0045d000-0x0045dfff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0045e000-0x0045efff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0045f000-0x0045ffff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00460000-0x00460fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00461000-0x00461fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00462000-0x00462fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00463000-0x00463fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00464000-0x00464fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00465000-0x00465fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00466000-0x00466fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00467000-0x00467fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00468000-0x00468fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00469000-0x00469fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0046a000-0x0046afff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0046b000-0x0046bfff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0046c000-0x0046cfff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0046d000-0x0046dfff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0046e000-0x0046efff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0046f000-0x0046ffff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00470000-0x00470fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00471000-0x00471fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00472000-0x00472fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00473000-0x00473fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00474000-0x00474fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00475000-0x00475fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00476000-0x00476fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00477000-0x00477fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00478000-0x00478fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x00479000-0x00479fff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0047a000-0x0047afff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0047b000-0x0047bfff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0047c000-0x0047cfff] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x0047d000-0x0047dfff] __alloc_memory_core_early+0x86/0xb8
On node 0 totalpages: 3584
memblock_virt_alloc_try_nid_nopanic: 147456 bytes align=0x0 nid=0
from=0x0 max_addr=0x0 __wake_up_parent+0xc/0x24
memblock_reserve: [0x0047e000-0x004a1fff]
memblock_virt_alloc_internal+0xe4/0x156
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 3584 pages, LIFO batch:0
memblock_virt_alloc_try_nid_nopanic: 4 bytes align=0x0 nid=0 from=0x0
max_addr=0x0 0x4
memblock_reserve: [0x004a2000-0x004a2003]
memblock_virt_alloc_internal+0xe4/0x156
On node 1 totalpages: 65536
memblock_virt_alloc_try_nid_nopanic: 2359296 bytes align=0x0 nid=1
from=0x0 max_addr=0x0 netdev_lower_get_next+0x2/0x22
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at mm/memblock.c:230
memblock_find_in_range_node+0x11c/0x1be
memblock: bottom-up allocation failed, memory hotunplug may be affected
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted
4.18.0-rc3-atari-01343-gf2fb5f2e09a97a3c-dirty #7
Stack from 003c3e20:
        003c3e20 0039cf44 00023800 00433000 ffffffff 00001000 00240000 000238aa
        00378734 000000e6 004285ac 00000009 00000000 003c3e58 003787c0 003c3e74
        003c3ea4 004285ac 00378734 000000e6 003787c0 00000000 00000000 00000001
        00000000 00000010 00000000 00428490 003e3856 ffffffff ffffffff 003c3ed0
        00044620 003c3ee0 00417a10 00240000 00000010 00000000 00000000 00000001
        00000000 00000001 00240000 00000000 00000000 00000000 00001000 003e3856
Call Trace: [<00023800>] __warn+0xa8/0xc2
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<00240000>] netdev_lower_get_next+0x2/0x22
 [<000238aa>] warn_slowpath_fmt+0x2e/0x36
 [<004285ac>] memblock_find_in_range_node+0x11c/0x1be
 [<004285ac>] memblock_find_in_range_node+0x11c/0x1be
 [<00428490>] memblock_find_in_range_node+0x0/0x1be
 [<00044620>] vprintk_func+0x66/0x6e
 [<00417a10>] memblock_virt_alloc_internal+0xd0/0x156
 [<00240000>] netdev_lower_get_next+0x2/0x22
 [<00240000>] netdev_lower_get_next+0x2/0x22
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<00417b8c>] memblock_virt_alloc_try_nid_nopanic+0x58/0x7a
 [<00240000>] netdev_lower_get_next+0x2/0x22
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<00010000>] EXPTBL+0x234/0x400
 [<00010000>] EXPTBL+0x234/0x400
 [<002f3644>] alloc_node_mem_map+0x4a/0x66
 [<00240000>] netdev_lower_get_next+0x2/0x22
 [<004155ca>] free_area_init_node+0xe2/0x29e
 [<00010000>] EXPTBL+0x234/0x400
 [<00411392>] paging_init+0x430/0x462
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<000427cc>] printk+0x0/0x1a
 [<00010000>] EXPTBL+0x234/0x400
 [<0041084c>] setup_arch+0x1b8/0x22c
 [<0040e020>] start_kernel+0x4a/0x40a
 [<0040d344>] _sinittext+0x344/0x9e8
random: get_random_bytes called from 0x3e75d2 with crng_init=0
---[ end trace 0000000000000000 ]---
memblock_reserve: [0x004a2010-0x006e200f]
memblock_virt_alloc_internal+0x116/0x156
  DMA zone: 576 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 65536 pages, LIFO batch:15
memblock_virt_alloc_try_nid_nopanic: 32 bytes align=0x0 nid=1 from=0x0
max_addr=0x0 0x20
memblock_reserve: [0x006e2010-0x006e202f]
memblock_virt_alloc_internal+0x116/0x156
NatFeats found (ARAnyM, 1.0)
memblock_reserve: [0x006e3000-0x007e2fff] __alloc_memory_core_early+0x86/0xb8
memblock_virt_alloc_try_nid: 118 bytes align=0x0 nid=-1 from=0x0
max_addr=0x0 0x76
memblock_reserve: [0x006e2030-0x006e20a5]
memblock_virt_alloc_internal+0xe4/0x156
memblock_virt_alloc_try_nid: 118 bytes align=0x0 nid=-1 from=0x0
max_addr=0x0 0x76
memblock_reserve: [0x006e20b0-0x006e2125]
memblock_virt_alloc_internal+0xe4/0x156
memblock_virt_alloc_try_nid: 118 bytes align=0x0 nid=-1 from=0x0
max_addr=0x0 0x76
memblock_reserve: [0x006e2130-0x006e21a5]
memblock_virt_alloc_internal+0xe4/0x156
memblock_virt_alloc_try_nid_nopanic: 4096 bytes align=0x1000 nid=-1
from=0x0 max_addr=0x0 kernel_pg_dir+0x0/0x1000
memblock_reserve: [0x007e3000-0x007e3fff]
memblock_virt_alloc_internal+0xe4/0x156
memblock_virt_alloc_try_nid_nopanic: 32768 bytes align=0x1000 nid=-1
from=0x0 max_addr=0x0 atari_keyboard_interrupt+0x94/0x2b2
memblock_reserve: [0x007e4000-0x007ebfff]
memblock_virt_alloc_internal+0xe4/0x156
memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 0x4
memblock_reserve: [0x006e21b0-0x006e21b3]
memblock_virt_alloc_internal+0xe4/0x156
memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 0x4
memblock_reserve: [0x006e21c0-0x006e21c3]
memblock_virt_alloc_internal+0xe4/0x156
memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 0x4
memblock_reserve: [0x006e21d0-0x006e21d3]
memblock_virt_alloc_internal+0xe4/0x156
memblock_virt_alloc_try_nid: 4 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 0x4
memblock_reserve: [0x006e21e0-0x006e21e3]
memblock_virt_alloc_internal+0xe4/0x156
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
memblock_virt_alloc_try_nid: 120 bytes align=0x0 nid=-1 from=0x0
max_addr=0x0 0x78
memblock_reserve: [0x006e21f0-0x006e2267]
memblock_virt_alloc_internal+0xe4/0x156
memblock_virt_alloc_try_nid: 67 bytes align=0x0 nid=-1 from=0x0
max_addr=0x0 0x43
memblock_reserve: [0x006e2270-0x006e22b2]
memblock_virt_alloc_internal+0xe4/0x156
memblock_virt_alloc_try_nid: 1024 bytes align=0x0 nid=-1 from=0x0
max_addr=0x0 0x400
memblock_reserve: [0x006e22c0-0x006e26bf]
memblock_virt_alloc_internal+0xe4/0x156
memblock_virt_alloc_try_nid: 1028 bytes align=0x0 nid=-1 from=0x0
max_addr=0x0 0x404
memblock_reserve: [0x006e26c0-0x006e2ac3]
memblock_virt_alloc_internal+0xe4/0x156
memblock_virt_alloc_try_nid: 160 bytes align=0x0 nid=-1 from=0x0
max_addr=0x0 0xa0
memblock_reserve: [0x006e2ad0-0x006e2b6f]
memblock_virt_alloc_internal+0xe4/0x156
__memblock_free_early: [0x000000007e3000-0x000000007e3fff] 0x7e3000
Built 2 zonelists, mobility grouping on.  Total pages: 68512
Kernel command line: root=/dev/sda1 video=atafb:tthigh debug=par
console=tty0 initcall_blacklist=atari_scsi_driver_init
BOOT_IMAGE=vmlinux
blacklisting initcall atari_scsi_driver_init
memblock_reserve: [0x006e2b70-0x006e2b7b] __alloc_memory_core_early+0x86/0xb8
memblock_reserve: [0x006e2b80-0x006e2b96] __alloc_memory_core_early+0x86/0xb8
memblock_virt_alloc_try_nid_nopanic: 262144 bytes align=0x0 nid=-1
from=0x0 max_addr=0x0 sys_membarrier+0x12/0xc6
memblock_reserve: [0x007ec000-0x0082bfff]
memblock_virt_alloc_internal+0xe4/0x156
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
memblock_virt_alloc_try_nid_nopanic: 131072 bytes align=0x0 nid=-1
from=0x0 max_addr=0x0 _I_CALL_TOP+0x660/0x1900
memblock_reserve: [0x0082c000-0x0084bfff]
memblock_virt_alloc_internal+0xe4/0x156
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Sorting __ex_table...
Memory: 267988K/276480K available (3036K kernel code, 304K rwdata,
792K rodata, 152K init, 168K bss, 8492K reserved, 0K cma-reserved)

Do you have a clue?
Thanks again!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Michal Hocko]

On Wed 04-07-18 09:44:14, Geert Uytterhoeven wrote:
[...]
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 0 at mm/memblock.c:230
> memblock_find_in_range_node+0x11c/0x1be
> memblock: bottom-up allocation failed, memory hotunplug may be affected

This only means that hotplugable memory might contain non-movable memory
now. But does your system even support memory hotplug. I would be really
surprised. So I guess we just want this instead
diff --git a/mm/memblock.c b/mm/memblock.c
index cc16d70b8333..c0dde95593fd 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -228,7 +228,8 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t size,
 		 * so we use WARN_ONCE() here to see the stack trace if
 		 * fail happens.
 		 */
-		WARN_ONCE(1, "memblock: bottom-up allocation failed, memory hotunplug may be affected\n");
+		WARN_ONCE(IS_ENABLED(CONFIG_MEMORY_HOTREMOVE),
+					"memblock: bottom-up allocvation failed, memory hotunplug may be affected\n");
 	}
 
 	return __memblock_find_range_top_down(start, end, size, align, nid,
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Geert Uytterhoeven]

Hi Michael,

On Wed, Jul 4, 2018 at 9:54 AM Michal Hocko <mhocko@kernel.org> wrote:
> On Wed 04-07-18 09:44:14, Geert Uytterhoeven wrote:
> [...]
> > ------------[ cut here ]------------
> > WARNING: CPU: 0 PID: 0 at mm/memblock.c:230
> > memblock_find_in_range_node+0x11c/0x1be
> > memblock: bottom-up allocation failed, memory hotunplug may be affected
>
> This only means that hotplugable memory might contain non-movable memory
> now. But does your system even support memory hotplug. I would be really

No it doesn't.

> surprised. So I guess we just want this instead
> diff --git a/mm/memblock.c b/mm/memblock.c
> index cc16d70b8333..c0dde95593fd 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -228,7 +228,8 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t size,
>                  * so we use WARN_ONCE() here to see the stack trace if
>                  * fail happens.
>                  */
> -               WARN_ONCE(1, "memblock: bottom-up allocation failed, memory hotunplug may be affected\n");
> +               WARN_ONCE(IS_ENABLED(CONFIG_MEMORY_HOTREMOVE),
> +                                       "memblock: bottom-up allocvation failed, memory hotunplug may be affected\n");
>         }
>
>         return __memblock_find_range_top_down(start, end, size, align, nid,

Thanks, that does the trick!

Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Vlastimil Babka]

On 07/04/2018 09:54 AM, Michal Hocko wrote:
> On Wed 04-07-18 09:44:14, Geert Uytterhoeven wrote:
> [...]
>> ------------[ cut here ]------------
>> WARNING: CPU: 0 PID: 0 at mm/memblock.c:230
>> memblock_find_in_range_node+0x11c/0x1be
>> memblock: bottom-up allocation failed, memory hotunplug may be affected
> 
> This only means that hotplugable memory might contain non-movable memory
> now. But does your system even support memory hotplug. I would be really
> surprised. So I guess we just want this instead
> diff --git a/mm/memblock.c b/mm/memblock.c
> index cc16d70b8333..c0dde95593fd 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -228,7 +228,8 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t size,
>  		 * so we use WARN_ONCE() here to see the stack trace if
>  		 * fail happens.
>  		 */
> -		WARN_ONCE(1, "memblock: bottom-up allocation failed, memory hotunplug may be affected\n");
> +		WARN_ONCE(IS_ENABLED(CONFIG_MEMORY_HOTREMOVE),
> +					"memblock: bottom-up allocvation failed, memory hotunplug may be affected\n");
                                                             ^ allocation               ^ hotremove
Makes sense, though.

>  	}
>  
>  	return __memblock_find_range_top_down(start, end, size, align, nid,
> 

Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Michal Hocko]

[CC Andrew - email thread starts
http://lkml.kernel.org/r/1530685696-14672-1-git-send-email-rppt@linux.vnet.ibm.com]

OK, so here we go with the full patch.

From 0e8432b875d98a7a0d3f757fce2caa8d16a8de15 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.com>
Date: Wed, 4 Jul 2018 14:31:46 +0200
Subject: [PATCH] memblock: do not complain about top-down allocations for
 !MEMORY_HOTREMOVE

Mike Rapoport is converting architectures from bootmem to noboodmem
allocator. While doing so for m68k Geert has noticed that he gets
a scary looking warning
WARNING: CPU: 0 PID: 0 at mm/memblock.c:230
memblock_find_in_range_node+0x11c/0x1be
memblock: bottom-up allocation failed, memory hotunplug may be affected
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted
4.18.0-rc3-atari-01343-gf2fb5f2e09a97a3c-dirty #7
Stack from 003c3e20:
        003c3e20 0039cf44 00023800 00433000 ffffffff 00001000 00240000 000238aa
        00378734 000000e6 004285ac 00000009 00000000 003c3e58 003787c0 003c3e74
        003c3ea4 004285ac 00378734 000000e6 003787c0 00000000 00000000 00000001
        00000000 00000010 00000000 00428490 003e3856 ffffffff ffffffff 003c3ed0
        00044620 003c3ee0 00417a10 00240000 00000010 00000000 00000000 00000001
        00000000 00000001 00240000 00000000 00000000 00000000 00001000 003e3856
Call Trace: [<00023800>] __warn+0xa8/0xc2
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<00240000>] netdev_lower_get_next+0x2/0x22
 [<000238aa>] warn_slowpath_fmt+0x2e/0x36
 [<004285ac>] memblock_find_in_range_node+0x11c/0x1be
 [<004285ac>] memblock_find_in_range_node+0x11c/0x1be
 [<00428490>] memblock_find_in_range_node+0x0/0x1be
 [<00044620>] vprintk_func+0x66/0x6e
 [<00417a10>] memblock_virt_alloc_internal+0xd0/0x156
 [<00240000>] netdev_lower_get_next+0x2/0x22
 [<00240000>] netdev_lower_get_next+0x2/0x22
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<00417b8c>] memblock_virt_alloc_try_nid_nopanic+0x58/0x7a
 [<00240000>] netdev_lower_get_next+0x2/0x22
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<00010000>] EXPTBL+0x234/0x400
 [<00010000>] EXPTBL+0x234/0x400
 [<002f3644>] alloc_node_mem_map+0x4a/0x66
 [<00240000>] netdev_lower_get_next+0x2/0x22
 [<004155ca>] free_area_init_node+0xe2/0x29e
 [<00010000>] EXPTBL+0x234/0x400
 [<00411392>] paging_init+0x430/0x462
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<000427cc>] printk+0x0/0x1a
 [<00010000>] EXPTBL+0x234/0x400
 [<0041084c>] setup_arch+0x1b8/0x22c
 [<0040e020>] start_kernel+0x4a/0x40a
 [<0040d344>] _sinittext+0x344/0x9e8

The warning is basically saying that a top-down allocation can break
memory hotremove because memblock allocation is not movable. But m68k
doesn't even support MEMORY_HOTREMOVE is there is no point to warn
about it.

Make the warning conditional only to configurations that care.

Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
 mm/memblock.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 03d48d8835ba..2acec4033389 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -227,7 +227,8 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t size,
 		 * so we use WARN_ONCE() here to see the stack trace if
 		 * fail happens.
 		 */
-		WARN_ONCE(1, "memblock: bottom-up allocation failed, memory hotunplug may be affected\n");
+		WARN_ONCE(IS_ENABLED(CONFIG_MEMORY_HOTREMOVE),
+					"memblock: bottom-up allocation failed, memory hotremove may be affected\n");
 	}
 
 	return __memblock_find_range_top_down(start, end, size, align, nid,
-- 
2.18.0

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Michal Hocko]

[CC Andrew - email thread starts
http://lkml.kernel.org/r/1530685696-14672-1-git-send-email-rppt@linux.vnet.ibm.com]

OK, so here we go with the full patch.

Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Mike Rapoport]

On Wed, Jul 04, 2018 at 02:36:27PM +0200, Michal Hocko wrote:
> [CC Andrew - email thread starts
> http://lkml.kernel.org/r/1530685696-14672-1-git-send-email-rppt@linux.vnet.ibm.com]
> 
> OK, so here we go with the full patch.
> 
> From 0e8432b875d98a7a0d3f757fce2caa8d16a8de15 Mon Sep 17 00:00:00 2001
> From: Michal Hocko <mhocko@suse.com>
> Date: Wed, 4 Jul 2018 14:31:46 +0200
> Subject: [PATCH] memblock: do not complain about top-down allocations for
>  !MEMORY_HOTREMOVE
> 
> Mike Rapoport is converting architectures from bootmem to noboodmem
> allocator. While doing so for m68k Geert has noticed that he gets
> a scary looking warning
> WARNING: CPU: 0 PID: 0 at mm/memblock.c:230
> memblock_find_in_range_node+0x11c/0x1be
> memblock: bottom-up allocation failed, memory hotunplug may be affected
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted
> 4.18.0-rc3-atari-01343-gf2fb5f2e09a97a3c-dirty #7
> Stack from 003c3e20:
>         003c3e20 0039cf44 00023800 00433000 ffffffff 00001000 00240000 000238aa
>         00378734 000000e6 004285ac 00000009 00000000 003c3e58 003787c0 003c3e74
>         003c3ea4 004285ac 00378734 000000e6 003787c0 00000000 00000000 00000001
>         00000000 00000010 00000000 00428490 003e3856 ffffffff ffffffff 003c3ed0
>         00044620 003c3ee0 00417a10 00240000 00000010 00000000 00000000 00000001
>         00000000 00000001 00240000 00000000 00000000 00000000 00001000 003e3856
> Call Trace: [<00023800>] __warn+0xa8/0xc2
>  [<00001000>] kernel_pg_dir+0x0/0x1000
>  [<00240000>] netdev_lower_get_next+0x2/0x22
>  [<000238aa>] warn_slowpath_fmt+0x2e/0x36
>  [<004285ac>] memblock_find_in_range_node+0x11c/0x1be
>  [<004285ac>] memblock_find_in_range_node+0x11c/0x1be
>  [<00428490>] memblock_find_in_range_node+0x0/0x1be
>  [<00044620>] vprintk_func+0x66/0x6e
>  [<00417a10>] memblock_virt_alloc_internal+0xd0/0x156
>  [<00240000>] netdev_lower_get_next+0x2/0x22
>  [<00240000>] netdev_lower_get_next+0x2/0x22
>  [<00001000>] kernel_pg_dir+0x0/0x1000
>  [<00417b8c>] memblock_virt_alloc_try_nid_nopanic+0x58/0x7a
>  [<00240000>] netdev_lower_get_next+0x2/0x22
>  [<00001000>] kernel_pg_dir+0x0/0x1000
>  [<00001000>] kernel_pg_dir+0x0/0x1000
>  [<00010000>] EXPTBL+0x234/0x400
>  [<00010000>] EXPTBL+0x234/0x400
>  [<002f3644>] alloc_node_mem_map+0x4a/0x66
>  [<00240000>] netdev_lower_get_next+0x2/0x22
>  [<004155ca>] free_area_init_node+0xe2/0x29e
>  [<00010000>] EXPTBL+0x234/0x400
>  [<00411392>] paging_init+0x430/0x462
>  [<00001000>] kernel_pg_dir+0x0/0x1000
>  [<000427cc>] printk+0x0/0x1a
>  [<00010000>] EXPTBL+0x234/0x400
>  [<0041084c>] setup_arch+0x1b8/0x22c
>  [<0040e020>] start_kernel+0x4a/0x40a
>  [<0040d344>] _sinittext+0x344/0x9e8
> 
> The warning is basically saying that a top-down allocation can break
> memory hotremove because memblock allocation is not movable. But m68k
> doesn't even support MEMORY_HOTREMOVE is there is no point to warn
> about it.
> 
> Make the warning conditional only to configurations that care.
> 
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
>  mm/memblock.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 03d48d8835ba..2acec4033389 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -227,7 +227,8 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t size,
>  		 * so we use WARN_ONCE() here to see the stack trace if
>  		 * fail happens.
>  		 */
> -		WARN_ONCE(1, "memblock: bottom-up allocation failed, memory hotunplug may be affected\n");
> +		WARN_ONCE(IS_ENABLED(CONFIG_MEMORY_HOTREMOVE),
> +					"memblock: bottom-up allocation failed, memory hotremove may be affected\n");

nit: isn't the warning indented too much?

>  	}
> 
>  	return __memblock_find_range_top_down(start, end, size, align, nid,
> -- 
> 2.18.0
> 
> -- 
> Michal Hocko
> SUSE Labs
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Michal Hocko]

On Wed 04-07-18 15:43:35, Mike Rapoport wrote:
> On Wed, Jul 04, 2018 at 02:36:27PM +0200, Michal Hocko wrote:
[...]
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index 03d48d8835ba..2acec4033389 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -227,7 +227,8 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t size,
> >  		 * so we use WARN_ONCE() here to see the stack trace if
> >  		 * fail happens.
> >  		 */
> > -		WARN_ONCE(1, "memblock: bottom-up allocation failed, memory hotunplug may be affected\n");
> > +		WARN_ONCE(IS_ENABLED(CONFIG_MEMORY_HOTREMOVE),
> > +					"memblock: bottom-up allocation failed, memory hotremove may be affected\n");
> 
> nit: isn't the warning indented too much?

this is what vim did for me. The string doesn't fit into 80 even if I
indented it to the first bracket. If you feel strongly I can do that
though.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Mike Rapoport]

On Wed, Jul 04, 2018 at 02:51:21PM +0200, Michal Hocko wrote:
> On Wed 04-07-18 15:43:35, Mike Rapoport wrote:
> > On Wed, Jul 04, 2018 at 02:36:27PM +0200, Michal Hocko wrote:
> [...]
> > > diff --git a/mm/memblock.c b/mm/memblock.c
> > > index 03d48d8835ba..2acec4033389 100644
> > > --- a/mm/memblock.c
> > > +++ b/mm/memblock.c
> > > @@ -227,7 +227,8 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t size,
> > >  		 * so we use WARN_ONCE() here to see the stack trace if
> > >  		 * fail happens.
> > >  		 */
> > > -		WARN_ONCE(1, "memblock: bottom-up allocation failed, memory hotunplug may be affected\n");
> > > +		WARN_ONCE(IS_ENABLED(CONFIG_MEMORY_HOTREMOVE),
> > > +					"memblock: bottom-up allocation failed, memory hotremove may be affected\n");
> > 
> > nit: isn't the warning indented too much?
> 
> this is what vim did for me. The string doesn't fit into 80 even if I
> indented it to the first bracket. If you feel strongly I can do that
> though.

Not really. With wrapping if looks better like this :) 
 
> -- 
> Michal Hocko
> SUSE Labs
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Geert Uytterhoeven]

Hi Michal,

On Wed, Jul 4, 2018 at 2:36 PM Michal Hocko <mhocko@kernel.org> wrote:
> [CC Andrew - email thread starts
> http://lkml.kernel.org/r/1530685696-14672-1-git-send-email-rppt@linux.vnet.ibm.com]
>
> OK, so here we go with the full patch.
>
> From 0e8432b875d98a7a0d3f757fce2caa8d16a8de15 Mon Sep 17 00:00:00 2001
> From: Michal Hocko <mhocko@suse.com>
> Date: Wed, 4 Jul 2018 14:31:46 +0200
> Subject: [PATCH] memblock: do not complain about top-down allocations for
>  !MEMORY_HOTREMOVE
>
> Mike Rapoport is converting architectures from bootmem to noboodmem

nobootmem

> allocator. While doing so for m68k Geert has noticed that he gets
> a scary looking warning
> WARNING: CPU: 0 PID: 0 at mm/memblock.c:230
> memblock_find_in_range_node+0x11c/0x1be
> memblock: bottom-up allocation failed, memory hotunplug may be affected

> The warning is basically saying that a top-down allocation can break
> memory hotremove because memblock allocation is not movable. But m68k
> doesn't even support MEMORY_HOTREMOVE is there is no point to warn

so there is

> about it.
>
> Make the warning conditional only to configurations that care.

Still, I'm wondering if the warning is really that unlikely on systems
that support
hotremove. Or is it due to the low amount of RAM on m68k boxes?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Michal Hocko]

On Wed 04-07-18 15:05:08, Geert Uytterhoeven wrote:
> Hi Michal,
> 
> On Wed, Jul 4, 2018 at 2:36 PM Michal Hocko <mhocko@kernel.org> wrote:
> > [CC Andrew - email thread starts
> > http://lkml.kernel.org/r/1530685696-14672-1-git-send-email-rppt@linux.vnet.ibm.com]
> >
> > OK, so here we go with the full patch.
> >
> > From 0e8432b875d98a7a0d3f757fce2caa8d16a8de15 Mon Sep 17 00:00:00 2001
> > From: Michal Hocko <mhocko@suse.com>
> > Date: Wed, 4 Jul 2018 14:31:46 +0200
> > Subject: [PATCH] memblock: do not complain about top-down allocations for
> >  !MEMORY_HOTREMOVE
> >
> > Mike Rapoport is converting architectures from bootmem to noboodmem
> 
> nobootmem

fixed

> 
> > allocator. While doing so for m68k Geert has noticed that he gets
> > a scary looking warning
> > WARNING: CPU: 0 PID: 0 at mm/memblock.c:230
> > memblock_find_in_range_node+0x11c/0x1be
> > memblock: bottom-up allocation failed, memory hotunplug may be affected
> 
> > The warning is basically saying that a top-down allocation can break
> > memory hotremove because memblock allocation is not movable. But m68k
> > doesn't even support MEMORY_HOTREMOVE is there is no point to warn
> 
> so there is

fixed

> > about it.
> >
> > Make the warning conditional only to configurations that care.
> 
> Still, I'm wondering if the warning is really that unlikely on systems
> that support
> hotremove. Or is it due to the low amount of RAM on m68k boxes?

Most likely yes. If you want to have full NUMA nodes hot-removable then
the BIOS/FW is supposed to mark them hotplug and then we rely on the
available memory on the low physical memory ranges (usually on not 0)
to cover all early boot allocations. Hack? Sure thing like the whole
memory hotremove, if you ask me.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2 0/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Greg Ungerer]

Hi Mike,

On 04/07/18 16:28, Mike Rapoport wrote:
> These patches switch m68k boot time memory allocators from bootmem to
> memblock + no_bootmem.
> 
> The first two patches update __ffs() and __va() definitions to be inline
> with other arches and asm-generic. This is required to avoid compilation
> warnings in mm/memblock.c and mm/nobootmem.c.
> 
> The third patch performs the actual switch of the boot time mm. Its
> changelog has detailed description of the changes.
> 
> I've tested the !MMU version with qemu-system-m68k -M mcf5208evb
> and the MMU version with q800 using qemu from [1].
> 
> I've also build tested allyesconfig and *_defconfig.
> 
> [1] https://github.com/vivier/qemu-m68k.git
> 
> v2:
> * fix reservation of the kernel text/data/bss for ColdFire MMU

I am happy with all of these, so for me:

Acked-by: Greg Ungerer <gerg@linux-m68k.org>

Regards
Greg



> Mike Rapoport (3):
>    m68k/bitops: convert __ffs to match generic declaration
>    m68k/page_no.h: force __va argument to be unsigned long
>    m68k: switch to MEMBLOCK + NO_BOOTMEM
> 
>   arch/m68k/Kconfig               |  3 +++
>   arch/m68k/include/asm/bitops.h  |  8 ++++++--
>   arch/m68k/include/asm/page_no.h |  2 +-
>   arch/m68k/kernel/setup_mm.c     | 14 ++++----------
>   arch/m68k/kernel/setup_no.c     | 20 ++++----------------
>   arch/m68k/mm/init.c             |  1 -
>   arch/m68k/mm/mcfmmu.c           | 13 +++++++------
>   arch/m68k/mm/motorola.c         | 35 +++++++++++------------------------
>   arch/m68k/sun3/config.c         |  4 ----
>   9 files changed, 36 insertions(+), 64 deletions(-)
> 

Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Michal Hocko]

On Wed 04-07-18 14:36:27, Michal Hocko wrote:
> [CC Andrew - email thread starts
> http://lkml.kernel.org/r/1530685696-14672-1-git-send-email-rppt@linux.vnet.ibm.com]

And updated version with typos fixed

From 63077ac611ff3f95afadf534902a8ab2984d5404 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.com>
Date: Wed, 4 Jul 2018 14:31:46 +0200
Subject: [PATCH] memblock: do not complain about top-down allocations for
 !MEMORY_HOTREMOVE

Mike Rapoport is converting architectures from bootmem to nobootmem
allocator. While doing so for m68k Geert has noticed that he gets
a scary looking warning
WARNING: CPU: 0 PID: 0 at mm/memblock.c:230
memblock_find_in_range_node+0x11c/0x1be
memblock: bottom-up allocation failed, memory hotunplug may be affected
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted
4.18.0-rc3-atari-01343-gf2fb5f2e09a97a3c-dirty #7
Stack from 003c3e20:
        003c3e20 0039cf44 00023800 00433000 ffffffff 00001000 00240000 000238aa
        00378734 000000e6 004285ac 00000009 00000000 003c3e58 003787c0 003c3e74
        003c3ea4 004285ac 00378734 000000e6 003787c0 00000000 00000000 00000001
        00000000 00000010 00000000 00428490 003e3856 ffffffff ffffffff 003c3ed0
        00044620 003c3ee0 00417a10 00240000 00000010 00000000 00000000 00000001
        00000000 00000001 00240000 00000000 00000000 00000000 00001000 003e3856
Call Trace: [<00023800>] __warn+0xa8/0xc2
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<00240000>] netdev_lower_get_next+0x2/0x22
 [<000238aa>] warn_slowpath_fmt+0x2e/0x36
 [<004285ac>] memblock_find_in_range_node+0x11c/0x1be
 [<004285ac>] memblock_find_in_range_node+0x11c/0x1be
 [<00428490>] memblock_find_in_range_node+0x0/0x1be
 [<00044620>] vprintk_func+0x66/0x6e
 [<00417a10>] memblock_virt_alloc_internal+0xd0/0x156
 [<00240000>] netdev_lower_get_next+0x2/0x22
 [<00240000>] netdev_lower_get_next+0x2/0x22
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<00417b8c>] memblock_virt_alloc_try_nid_nopanic+0x58/0x7a
 [<00240000>] netdev_lower_get_next+0x2/0x22
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<00010000>] EXPTBL+0x234/0x400
 [<00010000>] EXPTBL+0x234/0x400
 [<002f3644>] alloc_node_mem_map+0x4a/0x66
 [<00240000>] netdev_lower_get_next+0x2/0x22
 [<004155ca>] free_area_init_node+0xe2/0x29e
 [<00010000>] EXPTBL+0x234/0x400
 [<00411392>] paging_init+0x430/0x462
 [<00001000>] kernel_pg_dir+0x0/0x1000
 [<000427cc>] printk+0x0/0x1a
 [<00010000>] EXPTBL+0x234/0x400
 [<0041084c>] setup_arch+0x1b8/0x22c
 [<0040e020>] start_kernel+0x4a/0x40a
 [<0040d344>] _sinittext+0x344/0x9e8

The warning is basically saying that a top-down allocation can break
memory hotremove because memblock allocation is not movable. But m68k
doesn't even support MEMORY_HOTREMOVE so there is no point to warn
about it.

Make the warning conditional only to configurations that care.

Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
 mm/memblock.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 03d48d8835ba..2acec4033389 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -227,7 +227,8 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t size,
 		 * so we use WARN_ONCE() here to see the stack trace if
 		 * fail happens.
 		 */
-		WARN_ONCE(1, "memblock: bottom-up allocation failed, memory hotunplug may be affected\n");
+		WARN_ONCE(IS_ENABLED(CONFIG_MEMORY_HOTREMOVE),
+					"memblock: bottom-up allocation failed, memory hotremove may be affected\n");
 	}
 
 	return __memblock_find_range_top_down(start, end, size, align, nid,
-- 
2.18.0

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Michal Hocko]

On Wed 04-07-18 14:36:27, Michal Hocko wrote:
> [CC Andrew - email thread starts
> http://lkml.kernel.org/r/1530685696-14672-1-git-send-email-rppt@linux.vnet.ibm.com]

And updated version with typos fixed

Re: [PATCH v2 0/3] m68k: switch to MEMBLOCK + NO_BOOTMEM

[Geert Uytterhoeven]

Hi Mike,

On Wed, Jul 4, 2018 at 8:28 AM Mike Rapoport <rppt@linux.vnet.ibm.com> wrote:
> These patches switch m68k boot time memory allocators from bootmem to
> memblock + no_bootmem.
>
> The first two patches update __ffs() and __va() definitions to be inline
> with other arches and asm-generic. This is required to avoid compilation
> warnings in mm/memblock.c and mm/nobootmem.c.
>
> The third patch performs the actual switch of the boot time mm. Its
> changelog has detailed description of the changes.
>
> I've tested the !MMU version with qemu-system-m68k -M mcf5208evb
> and the MMU version with q800 using qemu from [1].
>
> I've also build tested allyesconfig and *_defconfig.
>
> [1] https://github.com/vivier/qemu-m68k.git
>
> v2:
> * fix reservation of the kernel text/data/bss for ColdFire MMU

Boots fine on the real Amiga, too. Let's assume it works on Sun 3 too.
Thanks a lot, applied and queued for v4.19.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds