[RFC PATCH]mm: fix potential infinite loop in dissolve_free_huge_pages()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



It is possible for some platforms, such as powerpc to set HPAGE_SHIFT to
0 to indicate huge pages not supported. 

When this is the case, hugetlbfs could be disabled during boot time:
hugetlbfs: disabling because there are no supported hugepage sizes

Then in dissolve_free_huge_pages(), order is kept maximum (64 for
64bits), and the for loop below won't end:
for (pfn = start_pfn; pfn < end_pfn; pfn += 1 << order)

The fix below returns directly if the order isn't set to a correct
value.

Signed-off-by: Li Zhong <zhong@xxxxxxxxxxxxxxxxxx>
---
 mm/hugetlb.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 2024bbd..a950817 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1093,6 +1093,10 @@ void dissolve_free_huge_pages(unsigned long start_pfn, unsigned long end_pfn)
 	for_each_hstate(h)
 		if (order > huge_page_order(h))
 			order = huge_page_order(h);
+
+	if (order == 8 * sizeof(void *))
+		return;
+
 	VM_BUG_ON(!IS_ALIGNED(start_pfn, 1 << order));
 	for (pfn = start_pfn; pfn < end_pfn; pfn += 1 << order)
 		dissolve_free_huge_page(pfn_to_page(pfn));


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]