linux-kernel - RE: [PATCH v3] mm/hugetlb: avoid hardcoding while checking if cma is enable

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]

Date:   Thu, 9 Jul 2020 23:45:33 +0000
From:   "Song Bao Hua (Barry Song)" <song.bao.hua@...ilicon.com>
To:     Mike Kravetz <mike.kravetz@...cle.com>,
        Roman Gushchin <guro@...com>
CC:     Andrew Morton <akpm@...ux-foundation.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linuxarm <linuxarm@...wei.com>,
        "Jonathan Cameron" <jonathan.cameron@...wei.com>
Subject: RE: [PATCH v3] mm/hugetlb: avoid hardcoding while checking if cma
 is enable



> -----Original Message-----
> From: Mike Kravetz [mailto:mike.kravetz@...cle.com]
> Sent: Friday, July 10, 2020 6:58 AM
> To: Song Bao Hua (Barry Song) <song.bao.hua@...ilicon.com>; Roman
> Gushchin <guro@...com>
> Cc: Andrew Morton <akpm@...ux-foundation.org>; linux-mm@...ck.org;
> linux-kernel@...r.kernel.org; Linuxarm <linuxarm@...wei.com>; Jonathan
> Cameron <jonathan.cameron@...wei.com>
> Subject: Re: [PATCH v3] mm/hugetlb: avoid hardcoding while checking if cma
> is enable
> 
> Looks like this produced a warning in linux-next.  I suspect it is due to the
> combination CONFIG_HUGETLB_PAGE && !CONFIG_CMA.
> 
> Instead of adding the routine hugetlb_cma_enabled() to scan the hugetlb_cma
> array, could we just use a boolean as follows?  It can simply be set in
> hugetlb_cma_reserve when we reserve CMA.

Maybe just use hugetlb_cma_size? If hugetlb_cma_size is not 0, someone is trying to use
cma, then bootmem for gigantic pages will be totally ignored according to discussion here:
https://lkml.org/lkml/2020/7/8/1288

if somebody sets a wrong hugetlb_cma_size which causes that cma is not reserved. 
It is the fault of users? We just need to document hugetlb_cma will overwrite bootmem
reservations?

> --
> Mike Kravetz
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index fab4485b9e52..92cb882cf287 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -46,6 +46,7 @@ unsigned int default_hstate_idx;
>  struct hstate hstates[HUGE_MAX_HSTATE];
> 
>  static struct cma *hugetlb_cma[MAX_NUMNODES];
> +static bool hugetlb_cma_enabled = false;
> 
>  /*
>   * Minimum page order among possible hugepage sizes, set to a proper value
> @@ -2571,7 +2572,7 @@ static void __init hugetlb_hstate_alloc_pages(struct
> hstate *h)
> 
>  	for (i = 0; i < h->max_huge_pages; ++i) {
>  		if (hstate_is_gigantic(h)) {
> -			if (IS_ENABLED(CONFIG_CMA) && hugetlb_cma[0]) {
> +			if (hugetlb_cma_enabled) {
>  				pr_warn_once("HugeTLB: hugetlb_cma is enabled, skip
> boot time allocation\n");
>  				break;
>  			}
> @@ -5708,6 +5709,7 @@ void __init hugetlb_cma_reserve(int order)
>  		reserved += size;
>  		pr_info("hugetlb_cma: reserved %lu MiB on node %d\n",
>  			size / SZ_1M, nid);
> +		hugetlb_cma_enabled = true;
> 
>  		if (reserved >= hugetlb_cma_size)
>  			break;

Thanks
Barry