linux-kernel - Re: [PATCH v2] arm64: mm: reserve hugetlb CMA after numa

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200617101824.GB3368@willie-the-truck>
Date:   Wed, 17 Jun 2020 11:18:25 +0100
From:   Will Deacon <will@...nel.org>
To:     Barry Song <song.bao.hua@...ilicon.com>
Cc:     catalin.marinas@....com, nsaenzjulienne@...e.de,
        steve.capper@....com, rppt@...ux.ibm.com,
        akpm@...ux-foundation.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, linuxarm@...wei.com,
        Matthias Brugger <matthias.bgg@...il.com>,
        Roman Gushchin <guro@...com>
Subject: Re: [PATCH v2] arm64: mm: reserve hugetlb CMA after numa_init

On Wed, Jun 17, 2020 at 10:19:24AM +1200, Barry Song wrote:
> hugetlb_cma_reserve() is called at the wrong place. numa_init has not been
> done yet. so all reserved memory will be located at node0.
> 
> Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages using cma")

Damn, wasn't CC'd on that :/

> Cc: Matthias Brugger <matthias.bgg@...il.com>
> Acked-by: Roman Gushchin <guro@...com>
> Signed-off-by: Barry Song <song.bao.hua@...ilicon.com>
> ---
>  -v2: add Fixes tag according to Matthias Brugger's comment
> 
>  arch/arm64/mm/init.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index e631e6425165..41914b483d54 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -404,11 +404,6 @@ void __init arm64_memblock_init(void)
>  	high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
>  
>  	dma_contiguous_reserve(arm64_dma32_phys_limit);
> -
> -#ifdef CONFIG_ARM64_4K_PAGES
> -	hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> -#endif

Why is this dependent on CONFIG_ARM64_4K_PAGES? We unconditionally
select ARCH_HAS_GIGANTIC_PAGE so this seems unnecessary.

> -
>  }
>  
>  void __init bootmem_init(void)
> @@ -424,6 +419,11 @@ void __init bootmem_init(void)
>  	min_low_pfn = min;
>  
>  	arm64_numa_init();
> +
> +#ifdef CONFIG_ARM64_4K_PAGES
> +	hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT);
> +#endif

A comment here wouldn't hurt, as it does look a lot more natural next
to dma_contiguous_reserve().

Will