linux-kernel - Re: [PATCH v3 3/5] hugetlb: be sure to free demoted CMA pages to CMA

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: <20211005093320.GC20412@linux>
Date:   Tue, 5 Oct 2021 11:33:21 +0200
From:   Oscar Salvador <osalvador@...e.de>
To:     Mike Kravetz <mike.kravetz@...cle.com>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        David Hildenbrand <david@...hat.com>,
        Michal Hocko <mhocko@...e.com>, Zi Yan <ziy@...dia.com>,
        Muchun Song <songmuchun@...edance.com>,
        Naoya Horiguchi <naoya.horiguchi@...ux.dev>,
        David Rientjes <rientjes@...gle.com>,
        "Aneesh Kumar K . V" <aneesh.kumar@...ux.ibm.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v3 3/5] hugetlb: be sure to free demoted CMA pages to CMA

On Fri, Oct 01, 2021 at 10:52:08AM -0700, Mike Kravetz wrote:
> When huge page demotion is fully implemented, gigantic pages can be
> demoted to a smaller huge page size.  For example, on x86 a 1G page
> can be demoted to 512 2M pages.  However, gigantic pages can potentially
> be allocated from CMA.  If a gigantic page which was allocated from CMA
> is demoted, the corresponding demoted pages needs to be returned to CMA.
> 
> Use the new interface cma_pages_valid() to determine if a non-gigantic
> hugetlb page should be freed to CMA.  Also, clear mapping field of these
> pages as expected by cma_release.
> 
> This also requires a change to CMA reservations for gigantic pages.
> Currently, the 'order_per_bit' is set to the gigantic page size.
> However, if gigantic pages can be demoted this needs to be set to the
> order of the smallest huge page.  At CMA reservation time we do not know

to the smallest, or to the next smaller? Would you mind elaborating why?

> @@ -3003,7 +3020,8 @@ static void __init hugetlb_init_hstates(void)
>  		 *   is not supported.
>  		 */
>  		if (!hstate_is_gigantic(h) ||
> -		    gigantic_page_runtime_supported()) {
> +		    gigantic_page_runtime_supported() ||
> +		    !hugetlb_cma_size || !(h->order <= HUGETLB_PAGE_ORDER)) {

I am bit lost in the CMA area, so bear with me.
We do not allow to demote if we specify we want hugetlb pages from the CMA?
Also, can h->order be smaller than HUGETLB_PAGE_ORDER? I though
HUGETLB_PAGE_ORDER was the smallest one.

The check for HUGETLB_PAGE_ORDER can probably be squashed into patch#1.


>  			for_each_hstate(h2) {
>  				if (h2 == h)
>  					continue;
> @@ -3555,6 +3573,8 @@ static ssize_t demote_size_store(struct kobject *kobj,
>  	if (!t_hstate)
>  		return -EINVAL;
>  	demote_order = t_hstate->order;
> +	if (demote_order < HUGETLB_PAGE_ORDER)
> +		return -EINVAL;

This could probably go in the first patch.


-- 
Oscar Salvador
SUSE Labs