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: <ZDkU6PuuDsUb82lr@dhcp22.suse.cz>
Date:   Fri, 14 Apr 2023 10:55:04 +0200
From:   Michal Hocko <mhocko@...e.com>
To:     Mel Gorman <mgorman@...hsingularity.net>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Oscar Salvador <OSalvador@...e.com>,
        Yuanxi Liu <y.liu@...uida.com>,
        David Hildenbrand <david@...hat.com>,
        Linux-MM <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: page_alloc: Assume huge tail pages are valid when
 allocating contiguous pages

On Fri 14-04-23 09:22:22, Mel Gorman wrote:
[...]
> +
> +		/*
> +		 * Do not migrate huge pages that span the size of the region
> +		 * being allocated contiguous. e.g. Do not migrate a 1G page
> +		 * for a 1G allocation request. CMA is an exception as the
> +		 * region may be reserved for hardware that requires physical
> +		 * memory without a MMU or scatter/gather capability.
> +		 *
> +		 * Note that the compound check is race-prone versus
> +		 * free/split/collapse but it should be safe and result in
> +		 * a premature skip or a useless migration attempt.
> +		 */
> +		if (PageHuge(page) && compound_nr(page) >= nr_pages &&
> +		    !is_migrate_cma_page(page)) {
> +			return false;

Is the CMA check working as expected? The function sounds quite generic
and I agree that it would make sense if it was generic but it is used
only for GB pages in fact and unless I am missing something it would
allow to migrate CMA pages and potentially allocate over that region
without any possibility to migrate GB page out so the CMA region would
be essentially unusable for CMA users. GB pages already have their CMA
allocator path before we get to alloc_contig_pages. Or do I miss
something?
-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ