linux-kernel - Re: [PATCH 1/2] mm/hugetlb: Introduce hugetlb_bad

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: <20160322233651.GA24819@hori1.linux.bs1.fc.nec.co.jp>
Date:	Tue, 22 Mar 2016 23:36:52 +0000
From:	Naoya Horiguchi <n-horiguchi@...jp.nec.com>
To:	Vaishali Thakkar <vaishali.thakkar@...cle.com>
CC:	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	Mike Kravetz <mike.kravetz@...cle.com>,
	Hillf Danton <hillf.zj@...baba-inc.com>,
	"Michal Hocko" <mhocko@...e.com>,
	Yaowei Bai <baiyaowei@...s.chinamobile.com>,
	"Dominik Dingel" <dingel@...ux.vnet.ibm.com>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH 1/2] mm/hugetlb: Introduce hugetlb_bad_size

On Tue, Mar 22, 2016 at 03:30:43PM +0530, Vaishali Thakkar wrote:
> When any unsupported hugepage size is specified, 'hugepagesz=' and
> 'hugepages=' should be ignored during command line parsing until any
> supported hugepage size is found. But currently incorrect number of
> hugepages are allocated when unsupported size is specified as it fails
> to ignore the 'hugepages=' command.
> 
> Test case:
> 
> Note that this is specific to x86 architecture.
> 
> Boot the kernel with command line option 'hugepagesz=256M hugepages=X'.
> After boot, dmesg output shows that X number of hugepages of the size 2M
> is pre-allocated instead of 0.
> 
> So, to handle such command line options, introduce new routine
> hugetlb_bad_size. The routine hugetlb_bad_size sets the global variable
> parsed_valid_hugepagesz. We are using parsed_valid_hugepagesz to save the
> state when unsupported hugepagesize is found so that we can ignore the
> 'hugepages=' parameters after that and then reset the variable when
> supported hugepage size is found.
> 
> The routine hugetlb_bad_size can be called while setting 'hugepagesz='
> parameter in an architecture specific code.

> Signed-off-by: Vaishali Thakkar <vaishali.thakkar@...cle.com>
> Cc: Mike Kravetz <mike.kravetz@...cle.com>
> Cc: Naoya Horiguchi <n-horiguchi@...jp.nec.com>
> Cc: Hillf Danton <hillf.zj@...baba-inc.com>
> Cc: Michal Hocko <mhocko@...e.com>
> Cc: Yaowei Bai <baiyaowei@...s.chinamobile.com>
> Cc: Dominik Dingel <dingel@...ux.vnet.ibm.com>
> Cc: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
> Cc: Paul Gortmaker <paul.gortmaker@...driver.com>
> Cc: Dave Hansen <dave.hansen@...ux.intel.com>

Maybe parsed_hstate can do what parsed_valid_hugepagesz does, but both
are __initdata so it's not a big deal.

Reviewed-by: Naoya Horiguchi <n-horiguchi@...jp.nec.com>

> ---
> The patch is having 2 checkpatch.pl warnings. I have just followed
> the current code to maintain consistency. If we decide to silent
> these warnings then may be we should silent those warnings as well.
> I am fine with any option whichever works best for everyone else. 
> ---
>  include/linux/hugetlb.h |  1 +
>  mm/hugetlb.c            | 14 +++++++++++++-
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 7d953c2..e44c578 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -338,6 +338,7 @@ int huge_add_to_page_cache(struct page *page, struct address_space *mapping,
>  /* arch callback */
>  int __init alloc_bootmem_huge_page(struct hstate *h);
>  
> +void __init hugetlb_bad_size(void);
>  void __init hugetlb_add_hstate(unsigned order);
>  struct hstate *size_to_hstate(unsigned long size);
>  
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 06058ea..44fae6a 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -51,6 +51,7 @@ __initdata LIST_HEAD(huge_boot_pages);
>  static struct hstate * __initdata parsed_hstate;
>  static unsigned long __initdata default_hstate_max_huge_pages;
>  static unsigned long __initdata default_hstate_size;
> +static bool __initdata parsed_valid_hugepagesz = true;
>  
>  /*
>   * Protects updates to hugepage_freelists, hugepage_activelist, nr_huge_pages,
> @@ -2659,6 +2660,11 @@ static int __init hugetlb_init(void)
>  subsys_initcall(hugetlb_init);
>  
>  /* Should be called on processing a hugepagesz=... option */
> +void __init hugetlb_bad_size(void)
> +{
> +	parsed_valid_hugepagesz = false;
> +}
> +
>  void __init hugetlb_add_hstate(unsigned int order)
>  {
>  	struct hstate *h;
> @@ -2691,11 +2697,17 @@ static int __init hugetlb_nrpages_setup(char *s)
>  	unsigned long *mhp;
>  	static unsigned long *last_mhp;
>  
> +	if (!parsed_valid_hugepagesz) {
> +		pr_warn("hugepages = %s preceded by "
> +			"an unsupported hugepagesz, ignoring\n", s);
> +		parsed_valid_hugepagesz = true;
> +		return 1;
> +	}
>  	/*
>  	 * !hugetlb_max_hstate means we haven't parsed a hugepagesz= parameter yet,
>  	 * so this hugepages= parameter goes to the "default hstate".
>  	 */
> -	if (!hugetlb_max_hstate)
> +	else if (!hugetlb_max_hstate)
>  		mhp = &default_hstate_max_huge_pages;
>  	else
>  		mhp = &parsed_hstate->max_huge_pages;
> -- 
> 2.1.4
>