linux-kernel - Re: [PATCH v5 4/5] mm: Make alloc_contig

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: <YFIRqtEt4ecfu1TN@dhcp22.suse.cz>
Date:   Wed, 17 Mar 2021 15:26:50 +0100
From:   Michal Hocko <mhocko@...e.com>
To:     Oscar Salvador <osalvador@...e.de>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        David Hildenbrand <david@...hat.com>,
        Muchun Song <songmuchun@...edance.com>,
        Mike Kravetz <mike.kravetz@...cle.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 4/5] mm: Make alloc_contig_range handle in-use hugetlb
 pages

On Wed 17-03-21 12:12:50, Oscar Salvador wrote:
> alloc_contig_range() will fail if it finds a HugeTLB page within the range,
> without a chance to handle them. Since HugeTLB pages can be migrated as any
> LRU or Movable page, it does not make sense to bail out without trying.
> Enable the interface to recognize in-use HugeTLB pages so we can migrate
> them, and have much better chances to succeed the call.
> 
> Signed-off-by: Oscar Salvador <osalvador@...e.de>
> Reviewed-by: Mike Kravetz <mike.kravetz@...cle.com>

Acked-by: Michal Hocko <mhocko@...e.com>

I am still not entirely happy about this
> @@ -2347,7 +2351,19 @@ int isolate_or_dissolve_huge_page(struct page *page)
>  	if (hstate_is_gigantic(h))
>  		return -ENOMEM;
>  
> -	return alloc_and_dissolve_huge_page(h, head);
> +retry:
> +	if (page_count(head) && isolate_huge_page(head, list)) {
> +		ret = 0;
> +	} else if (!page_count(head)) {
> +		ret = alloc_and_dissolve_huge_page(h, head);
> +
> +		if (ret == -EBUSY && try_again) {
> +			try_again = false;
> +			goto retry;
> +		}
> +	}
> +
> +	return ret;
>  }

it would be imho better to retry inside alloc_and_dissolve_huge_page
because it already has its retry logic implemented.

But not something I will insist on.

-- 
Michal Hocko
SUSE Labs