mm/kconfig: Drop redundant dependency wrappers
Subsystems (2)
PATCH 1/1 mm/kconfig: Drop redundant dependency wrappers
From: Kaitao Cheng <[email protected]>
Some mm Kconfig entries repeat dependencies that are already expressed by their surrounding blocks or menus.
The zsmalloc allocator options menu already depends on ZSMALLOC, so the outer if ZSMALLOC block does not add any extra constraint. MEMORY_HOTREMOVE and MHP_MEMMAP_ON_MEMORY are both inside the if MEMORY_HOTPLUG block, so their local depends on MEMORY_HOTPLUG entries are redundant.
PTE_MARKER_UFFD_WP is the only entry under if USERFAULTFD. Move the USERFAULTFD dependency into the symbol itself and combine it with the architecture support dependency.
This keeps the same visibility and defaults while avoiding duplicate dependency expressions.
--- mm/Kconfig | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-)
mm/Kconfig +1 -9
@@ -125,8 +125,6 @@ config ZSWAP_COMPRESSOR_DEFAULT config ZSMALLOC tristate -if ZSMALLOC - menu "Zsmalloc allocator options" depends on ZSMALLOC
@@ -161,8 +159,6 @@ config ZSMALLOC_CHAIN_SIZE endmenu -endif - menu "Slab allocator options" config SLUB
@@ -591,12 +587,10 @@ endchoice config MEMORY_HOTREMOVE bool "Allow for memory hot remove" select HAVE_BOOTMEM_INFO_NODE if X86_64 - depends on MEMORY_HOTPLUG select MIGRATION config MHP_MEMMAP_ON_MEMORY def_bool y - depends on MEMORY_HOTPLUG depends on ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE endif # MEMORY_HOTPLUG
@@ -1391,17 +1385,15 @@ menuconfig USERFAULTFD Enable the userfaultfd() system call that allows to intercept and handle page faults in userland. -if USERFAULTFD config PTE_MARKER_UFFD_WP bool "Userfaultfd write protection support for shmem/hugetlbfs" default y - depends on HAVE_ARCH_USERFAULTFD_WP + depends on USERFAULTFD && HAVE_ARCH_USERFAULTFD_WP help Allows to create marker PTEs for userfaultfd write protection purposes. It is required to enable userfaultfd write protection on file-backed memory types like shmem and hugetlbfs. -endif # USERFAULTFD # multi-gen LRU { config LRU_GEN
Signature · 1 line
2.50.1 (Apple Git-155)
Quoted 14 lines · Kaitao Cheng
From: Kaitao Cheng <[email protected]>
Some mm
Kconfigentries repeat dependencies that are already expressed by their surrounding blocks or menus.The zsmalloc allocator options menu already depends on ZSMALLOC, so the outer if ZSMALLOC block does not add any extra constraint.
MEMORY_HOTREMOVEandMHP_MEMMAP_ON_MEMORYare both inside the ifMEMORY_HOTPLUGblock, so their local depends onMEMORY_HOTPLUGentries are redundant.
PTE_MARKER_UFFD_WPis the only entry under if USERFAULTFD. Move the USERFAULTFD dependency into the symbol itself and combine it with the architecture support dependency.
Quoted 6 lines
This keeps the same visibility and defaults while avoiding duplicate dependency expressions.
Suggested-by Julian Braha <[email protected]>Signed-off-by Kaitao Cheng <[email protected]>---
Signature · 3 lines
Cheers, David
Quoted 7 lines · Kaitao Cheng
[...]
This keeps the same visibility and defaults while avoiding duplicate dependency expressions.
Suggested-by Julian Braha <[email protected]>Signed-off-by Kaitao Cheng <[email protected]>
LGTM!
Quoted 7 lines
mm/Kconfig +0
-0
mm/Kconfig endchoice · line 599
Quoted 9 lines
mm/Kconfig +0
-2@@ -591,12 +587,10 @@ endchoice config MEMORY_HOTREMOVE bool "Allow for memory hot remove" select HAVE_BOOTMEM_INFO_NODE if X86_64 - depends on MEMORY_HOTPLUG select MIGRATION config MHP_MEMMAP_ON_MEMORY def_bool y - depends on MEMORY_HOTPLUG
Honestly I hate that we have both if and depends on, I'd rather we just had depends on so we had consistency everywhere :) but it's not your fault, just a gripe with Kconfig in general! :)
mm/Kconfig menuconfig USERFAULTFD · line 1399
Quoted 8 lines
mm/Kconfig +0
-0@@ -1391,17 +1385,15 @@ menuconfig USERFAULTFD[ ... skip 12 lines ... ]
mm/Kconfig +0
-1purposes. It is required to enable userfaultfd write protection on file-backed memory types like shmem and hugetlbfs. -endif # USERFAULTFD # multi-gen LRU { config LRU_GEN
Cheers, Lorenzo
Signature · 1 line
Lorenzo Stoakes (ARM) <[email protected]>