Re: [PATCH v6 05/12] mm: HUGE_VMAP arch support cleanup
From: Andrew Morton <akpm@linux-foundation.org>
Date: 2020-08-21 20:14:26
Also in:
linux-arm-kernel, linux-mm, linuxppc-dev, lkml
From: Andrew Morton <akpm@linux-foundation.org>
Date: 2020-08-21 20:14:26
Also in:
linux-arm-kernel, linux-mm, linuxppc-dev, lkml
On Sat, 22 Aug 2020 01:12:09 +1000 Nicholas Piggin [off-list ref] wrote:
This changes the awkward approach where architectures provide init functions to determine which levels they can provide large mappings for, to one where the arch is queried for each call. This removes code and indirection, and allows constant-folding of dead code for unsupported levels. This also adds a prot argument to the arch query. This is unused currently but could help with some architectures (e.g., some powerpc processors can't map uncacheable memory with large pages).--- a/arch/arm64/include/asm/vmalloc.h +++ b/arch/arm64/include/asm/vmalloc.h@@ -1,4 +1,12 @@ #ifndef _ASM_ARM64_VMALLOC_H #define _ASM_ARM64_VMALLOC_H +#include <asm/page.h> + +#ifdef CONFIG_HAVE_ARCH_HUGE_VMAP +bool arch_vmap_p4d_supported(pgprot_t prot); +bool arch_vmap_pud_supported(pgprot_t prot); +bool arch_vmap_pmd_supported(pgprot_t prot); +#endif
Moving these out of generic code and into multiple arch headers is unfortunate. Can we leave them in include/linux/somewhere? And remove the ifdefs, if so inclined - they just move the build error from link-time to compile-time, and such an error shouldn't occur!