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: <Zsx3ULRaVu5Lh46Q@pc636>
Date: Mon, 26 Aug 2024 14:38:40 +0200
From: Uladzislau Rezki <urezki@...il.com>
To: Michal Hocko <mhocko@...e.com>
Cc: Uladzislau Rezki <urezki@...il.com>, 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 Mon, Aug 26, 2024 at 09:52:42AM +0200, Michal Hocko wrote:
> 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?
> 
1. So, for bulk we have below:

/* gfp_t bulk_gfp = gfp & ~__GFP_NOFAIL; */

I am not sure if we need it but it says it does not support it which
is not clear for me why we have to drop __GFP_NOFAIL for bulk(). There
is a fallback to a single page allocator. If passing __GFP_NOFAIL does
not trigger any warning or panic a system, then i do not follow why
we drop that flag.

Is that odd?

2. High-order allocations. Do you think we should not care much about
it when __GFP_NOFAIL is set? Same here, there is a fallback for order-0
if "high" fails, it is more likely NO_FAIL succeed for order-0. Thus
keeping NOFAIL for high-order sounds like not a good approach to me.

3. "... at the same place?"
Do you mean in the __vmalloc_node_range_noprof()?

__vmalloc_node_range_noprof()
    -> __vmalloc_area_node(gfp_mask)
        -> vm_area_alloc_pages()

if, so it is not straight forward, i.e. there is one more allocation:

<snip>
static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
				 pgprot_t prot, unsigned int page_shift,
				 int node)
{
...
	/* Please note that the recursion is strictly bounded. */
	if (array_size > PAGE_SIZE) {
		area->pages = __vmalloc_node_noprof(array_size, 1, nested_gfp, node,
					area->caller);
	} else {
		area->pages = kmalloc_node_noprof(array_size, nested_gfp, node);
	}
...
}
<snip>

whereas it is easier to do it inside of the __vmalloc_area_node().

>
> Not that I care about this much TBH. It is an improvement to drop all
> the NOFAIL specifics from vm_area_alloc_pages.
> 
I agree. I also do not like modifying gfp flags on different levels and
different cases. To me there is only one case. It is high-order requests
with NOFAIL. For this i think we should keep our approach, i mean
dropping NOFAIL and repeat because we have a fallback.

--
Uladzislau Rezki