On 1/17/22 6:46 PM, Nicholas Piggin wrote: >> This all sounds very fragile to me. Every time a new architecture would >> get added for huge vmalloc() support, the developer needs to know to go >> find that architecture's module_alloc() and add this flag. > This is documented in the Kconfig. > > # > # Archs that select this would be capable of PMD-sized vmaps (i.e., > # arch_vmap_pmd_supported() returns true), and they must make no assumptions > # that vmalloc memory is mapped with PAGE_SIZE ptes. The VM_NO_HUGE_VMAP flag > # can be used to prohibit arch-specific allocations from using hugepages to > # help with this (e.g., modules may require it). > # > config HAVE_ARCH_HUGE_VMALLOC > depends on HAVE_ARCH_HUGE_VMAP > bool > > Is it really fair to say it's *very* fragile? Surely it's reasonable to > read the (not very long) documentation ad understand the consequences for > the arch code before enabling it. Very fragile or not, I think folks are likely to get it wrong. It would be nice to have it default *everyone* to safe and slow and make *sure* they go look at the architecture modules code itself before enabling this for modules. Just from that Kconfig text, I don't think I'd know off the top of my head what do do for x86, or what code I needed to go touch.
