Re: linux-next: manual merge of the akpm-current tree with the arm64 tree

[Will Deacon <will@kernel.org>]

On Thu, Jul 16, 2020 at 06:00:12PM +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   arch/arm64/mm/init.c
> 
> between commit:
> 
>   abb7962adc80 ("arm64/hugetlb: Reserve CMA areas for gigantic pages on 16K and 64K configs")
> 
> from the arm64 tree and commit:
> 
>   10d44973d8ab ("mm/hugetlb: split hugetlb_cma in nodes with memory")
> 
> from the akpm-current tree.

[...]

> diff --cc arch/arm64/mm/init.c
> index f8c19c6c8e71,ee551d71c4dd..000000000000
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@@ -421,22 -421,21 +421,21 @@@ void __init bootmem_init(void
>   	arm64_numa_init();
>   
>   	/*
> - 	 * must be done after arm64_numa_init() which calls numa_init() to
> - 	 * initialize node_online_map that gets used in hugetlb_cma_reserve()
> - 	 * while allocating required CMA size across online nodes.
> + 	 * sparse_init() tries to allocate memory from memblock, so must be
> + 	 * done after the fixed reservations
>   	 */
> - #if defined(CONFIG_HUGETLB_PAGE) && defined(CONFIG_CMA)
> - 	arm64_hugetlb_cma_reserve();
> - #endif
> + 	sparse_init();
> + 	zone_sizes_init(min, max);
>   
>   	/*
> - 	 * Sparsemem tries to allocate bootmem in memory_present(), so must be
> - 	 * done after the fixed reservations.
> + 	 * must be done after zone_sizes_init() which calls free_area_init()
> + 	 * that calls node_set_state() to initialize node_states[N_MEMORY]
> + 	 * because hugetlb_cma_reserve() will scan over nodes with N_MEMORY
> + 	 * state
>   	 */
> - 	memblocks_present();
> - 
> - 	sparse_init();
> - 	zone_sizes_init(min, max);
>  -#ifdef CONFIG_ARM64_4K_PAGES
>  -	hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> ++#if defined(CONFIG_HUGETLB_PAGE) && defined(CONFIG_CMA)
> ++	arm64_hugetlb_cma_reserve();
> + #endif

Thanks, looks good to me, although we might be in for a hairier conflict
if the discussion at [1] ends up with a patch for merging.

Will

[1] https://lore.kernel.org/r/359ea1d0-b1fd-d09f-d28a-a44655834277@oracle.com