linux-kernel - Re: [RESEND PATCH v1] mm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0

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: <Zsw0Sv9alVUb1DV2@tiehlicka>
Date: Mon, 26 Aug 2024 09:52:42 +0200
From: Michal Hocko <mhocko@...e.com>
To: Uladzislau Rezki <urezki@...il.com>
Cc: Hailong Liu <hailong.liu@...o.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Barry Song <21cnbao@...il.com>,
	Christoph Hellwig <hch@...radead.org>,
	Vlastimil Babka <vbabka@...e.cz>,
	Tangquan Zheng <zhengtangquan@...o.com>, stable@...r.kernel.org,
	Baoquan He <bhe@...hat.com>, Matthew Wilcox <willy@...radead.org>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH v1] mm/vmalloc: fix page mapping if
 vm_area_alloc_pages() with high order fallback to order 0

On Fri 23-08-24 18:42:47, Uladzislau Rezki wrote:
[...]
> @@ -3666,7 +3655,16 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
>  	set_vm_area_page_order(area, page_shift - PAGE_SHIFT);
>  	page_order = vm_area_page_order(area);
>  
> -	area->nr_pages = vm_area_alloc_pages(gfp_mask | __GFP_NOWARN,
> +	/*
> +	 * Higher order nofail allocations are really expensive and
> +	 * potentially dangerous (pre-mature OOM, disruptive reclaim
> +	 * and compaction etc.
> +	 *
> +	 * Please note, the __vmalloc_node_range_noprof() falls-back
> +	 * to order-0 pages if high-order attempt has been unsuccessful.
> +	 */
> +	area->nr_pages = vm_area_alloc_pages(page_order ?
> +		gfp_mask &= ~__GFP_NOFAIL : gfp_mask | __GFP_NOWARN,
>  		node, page_order, nr_small_pages, area->pages);
>  
>  	atomic_long_add(area->nr_pages, &nr_vmalloc_pages);
> <snip>
> 
> Is that aligned with your wish?

I am not a great fan of modifying gfp_mask inside the ternary operator
like that. It makes the code harder to read. Is there any actual reason
to simply drop GFP_NOFAIL unconditionally and rely do the NOFAIL
handling for all orders at the same place?

Not that I care about this much TBH. It is an improvement to drop all
the NOFAIL specifics from vm_area_alloc_pages.

-- 
Michal Hocko
SUSE Labs