Skip to content

Commit 9becb68

Browse files
committed
kvmalloc: use vmalloc_huge for vmalloc allocations
Since commit 559089e ("vmalloc: replace VM_NO_HUGE_VMAP with VM_ALLOW_HUGE_VMAP"), the use of hugepage mappings for vmalloc is an opt-in strategy, because it caused a number of problems that weren't noticed until x86 enabled it too. One of the issues was fixed by Nick Piggin in commit 3b8000a ("mm/vmalloc: huge vmalloc backing pages should be split rather than compound"), but I'm still worried about page protection issues, and VM_FLUSH_RESET_PERMS in particular. However, like the hash table allocation case (commit f2edd11: "page_alloc: use vmalloc_huge for large system hash"), the use of kvmalloc() should be safe from any such games, since the returned pointer might be a SLUB allocation, and as such no user should reasonably be using it in any odd ways. We also know that the allocations are fairly large, since it falls back to the vmalloc case only when a kmalloc() fails. So using a hugepage mapping seems both safe and relevant. This patch does show a weakness in the opt-in strategy: since the opt-in flag is in the 'vm_flags', not the usual gfp_t allocation flags, very few of the usual interfaces actually expose it. That's not much of an issue in this case that already used one of the fairly specialized low-level vmalloc interfaces for the allocation, but for a lot of other vmalloc() users that might want to opt in, it's going to be very inconvenient. We'll either have to fix any compatibility problems, or expose it in the gfp flags (__GFP_COMP would have made a lot of sense) to allow normal vmalloc() users to use hugepage mappings. That said, the cases that really matter were probably already taken care of by the hash tabel allocation. Link: https://lore.kernel.org/all/20220415164413.2727220-1-song@kernel.org/ Link: https://lore.kernel.org/all/CAHk-=whao=iosX1s5Z4SF-ZGa-ebAukJoAdUJFk5SPwnofV+Vg@mail.gmail.com/ Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Paul Menzel <pmenzel@molgen.mpg.de> Cc: Song Liu <songliubraving@fb.com> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
1 parent f2edd11 commit 9becb68

File tree

1 file changed

+9
-2
lines changed

1 file changed

+9
-2
lines changed

mm/util.c

Lines changed: 9 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -592,8 +592,15 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node)
592592
return NULL;
593593
}
594594

595-
return __vmalloc_node(size, 1, flags, node,
596-
__builtin_return_address(0));
595+
/*
596+
* kvmalloc() can always use VM_ALLOW_HUGE_VMAP,
597+
* since the callers already cannot assume anything
598+
* about the resulting pointer, and cannot play
599+
* protection games.
600+
*/
601+
return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END,
602+
flags, PAGE_KERNEL, VM_ALLOW_HUGE_VMAP,
603+
node, __builtin_return_address(0));
597604
}
598605
EXPORT_SYMBOL(kvmalloc_node);
599606

0 commit comments

Comments
 (0)