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: <ZqI5V+5E3RNhuSwx@MiWiFi-R3L-srv>
Date: Thu, 25 Jul 2024 19:39:03 +0800
From: Baoquan He <bhe@...hat.com>
To: hailong.liu@...o.com
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Uladzislau Rezki <urezki@...il.com>,
	Christoph Hellwig <hch@...radead.org>,
	Lorenzo Stoakes <lstoakes@...il.com>,
	Vlastimil Babka <vbabka@...e.cz>, Michal Hocko <mhocko@...e.com>,
	Barry Song <21cnbao@...il.com>,
	Matthew Wilcox <willy@...radead.org>,
	"Tangquan . Zheng" <zhengtangquan@...o.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2] mm/vmalloc: fix incorrect
 __vmap_pages_range_noflush() if vm_area_alloc_pages() from high order
 fallback to order0

On 07/25/24 at 11:53am, hailong.liu@...o.com wrote:
> From: "Hailong.Liu" <hailong.liu@...o.com>
> 
> The scenario where the issue occurs is as follows:
> CONFIG: vmap_allow_huge = true && 2M is for PMD_SIZE
> kvmalloc(2M, __GFP_NOFAIL|GFP_XXX)
>     __vmalloc_node_range(vm_flags=VM_ALLOW_HUGE_VMAP)
>         vm_area_alloc_pages(order=9) --->allocs order9 failed and fallback to order0
>                                         and phys_addr is aligned with PMD_SIZE
>             vmap_pages_range
>                 vmap_pages_range_noflush
>                     __vmap_pages_range_noflush(page_shift = 21) ----> incorrect vmap *huge* here
> 
> In fact, as long as page_shift is not equal to PAGE_SHIFT, there
> might be issues with the __vmap_pages_range_noflush().
> 
> The patch also remove VM_ALLOW_HUGE_VMAP in kvmalloc_node(), There
> are several reasons for this:
> - This increases memory footprint because ALIGNMENT.
> - This increases the likelihood of kvmalloc allocation failures.
> - Without this it fixes the origin issue of kvmalloc with __GFP_NOFAIL may return NULL.
> Besides if drivers want to vmap huge, user vmalloc_huge instead.

Seem there are two issues you are folding into one patch:

one is the wrong informatin passed into __vmap_pages_range_noflush();
the other is you want to take off VM_ALLOW_HUGE_VMAP on kvmalloc().

About the 1st one, do you think below draft is OK to you?

Pass out the fall back order and adjust the order and shift for later
usage, mainly for vmap_pages_range().

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 260897b21b11..5ee9ae518f3d 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -3508,9 +3508,9 @@ EXPORT_SYMBOL_GPL(vmap_pfn);
 
 static inline unsigned int
 vm_area_alloc_pages(gfp_t gfp, int nid,
-		unsigned int order, unsigned int nr_pages, struct page **pages)
+		unsigned int *page_order, unsigned int nr_pages, struct page **pages)
 {
-	unsigned int nr_allocated = 0;
+	unsigned int nr_allocated = 0, order = *page_order;
 	gfp_t alloc_gfp = gfp;
 	bool nofail = gfp & __GFP_NOFAIL;
 	struct page *page;
@@ -3611,6 +3611,7 @@ vm_area_alloc_pages(gfp_t gfp, int nid,
 		cond_resched();
 		nr_allocated += 1U << order;
 	}
+	*page_order = order;
 
 	return nr_allocated;
 }
@@ -3654,7 +3655,7 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
 	page_order = vm_area_page_order(area);
 
 	area->nr_pages = vm_area_alloc_pages(gfp_mask | __GFP_NOWARN,
-		node, page_order, nr_small_pages, area->pages);
+		node, &page_order, nr_small_pages, area->pages);
 
 	atomic_long_add(area->nr_pages, &nr_vmalloc_pages);
 	if (gfp_mask & __GFP_ACCOUNT) {
@@ -3686,6 +3687,10 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
 		goto fail;
 	}
 
+
+	set_vm_area_page_order(area, page_order);
+	page_shift = page_order + PAGE_SHIFT;
+
 	/*
 	 * page tables allocations ignore external gfp mask, enforce it
 	 * by the scope API


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ