kernel-hacking: move kernel testing and coverage options to same submenu

Move error injection, coverage, testing options to a new top level
submenu 'Kernel Testing and Coverage'.  They are all for test purpose.

Link: http://lkml.kernel.org/r/20190909144453.3520-5-changbin.du@gmail.com
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 8526397f06886bed08c8118c727b9bc9d0be916a..e27c8ced31665d2c532097436e64c59e1abd3c05 100644 (file)
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -764,53 +764,6 @@ source "lib/Kconfig.kasan"
 
 endmenu # "Memory Debugging"
 
-config ARCH_HAS_KCOV
-       bool
-       help
-         An architecture should select this when it can successfully
-         build and run with CONFIG_KCOV. This typically requires
-         disabling instrumentation for some early boot code.
-
-config CC_HAS_SANCOV_TRACE_PC
-       def_bool $(cc-option,-fsanitize-coverage=trace-pc)
-
-config KCOV
-       bool "Code coverage for fuzzing"
-       depends on ARCH_HAS_KCOV
-       depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
-       select DEBUG_FS
-       select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC
-       help
-         KCOV exposes kernel code coverage information in a form suitable
-         for coverage-guided fuzzing (randomized testing).
-
-         If RANDOMIZE_BASE is enabled, PC values will not be stable across
-         different machines and across reboots. If you need stable PC values,
-         disable RANDOMIZE_BASE.
-
-         For more details, see Documentation/dev-tools/kcov.rst.
-
-config KCOV_ENABLE_COMPARISONS
-       bool "Enable comparison operands collection by KCOV"
-       depends on KCOV
-       depends on $(cc-option,-fsanitize-coverage=trace-cmp)
-       help
-         KCOV also exposes operands of every comparison in the instrumented
-         code along with operand sizes and PCs of the comparison instructions.
-         These operands can be used by fuzzing engines to improve the quality
-         of fuzzing coverage.
-
-config KCOV_INSTRUMENT_ALL
-       bool "Instrument all code by default"
-       depends on KCOV
-       default y
-       help
-         If you are doing generic system call fuzzing (like e.g. syzkaller),
-         then you will want to instrument the whole kernel and you should
-         say y here. If you are doing more targeted fuzzing (like e.g.
-         filesystem fuzzing with AFL) then you will want to enable coverage
-         for more specific subsets of files, and should say n here.
-
 config DEBUG_SHIRQ
        bool "Debug shared IRQ handlers"
        depends on DEBUG_KERNEL
@@ -1480,6 +1433,54 @@ config CPU_HOTPLUG_STATE_CONTROL
 
          Say N if your are unsure.
 
+config LATENCYTOP
+       bool "Latency measuring infrastructure"
+       depends on DEBUG_KERNEL
+       depends on STACKTRACE_SUPPORT
+       depends on PROC_FS
+       select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM && !ARC && !X86
+       select KALLSYMS
+       select KALLSYMS_ALL
+       select STACKTRACE
+       select SCHEDSTATS
+       select SCHED_DEBUG
+       help
+         Enable this option if you want to use the LatencyTOP tool
+         to find out which userspace is blocking on what kernel operations.
+
+source "kernel/trace/Kconfig"
+
+config PROVIDE_OHCI1394_DMA_INIT
+       bool "Remote debugging over FireWire early on boot"
+       depends on PCI && X86
+       help
+         If you want to debug problems which hang or crash the kernel early
+         on boot and the crashing machine has a FireWire port, you can use
+         this feature to remotely access the memory of the crashed machine
+         over FireWire. This employs remote DMA as part of the OHCI1394
+         specification which is now the standard for FireWire controllers.
+
+         With remote DMA, you can monitor the printk buffer remotely using
+         firescope and access all memory below 4GB using fireproxy from gdb.
+         Even controlling a kernel debugger is possible using remote DMA.
+
+         Usage:
+
+         If ohci1394_dma=early is used as boot parameter, it will initialize
+         all OHCI1394 controllers which are found in the PCI config space.
+
+         As all changes to the FireWire bus such as enabling and disabling
+         devices cause a bus reset and thereby disable remote DMA for all
+         devices, be sure to have the cable plugged and FireWire enabled on
+         the debugging host before booting the debug target for debugging.
+
+         This code (~1k) is freed after boot. By then, the firewire stack
+         in charge of the OHCI-1394 controllers should be used instead.
+
+         See Documentation/debugging-via-ohci1394.txt for more information.
+
+source "lib/kunit/Kconfig"
+
 config NOTIFIER_ERROR_INJECTION
        tristate "Notifier error injection"
        depends on DEBUG_KERNEL
@@ -1638,53 +1639,57 @@ config FAULT_INJECTION_STACKTRACE_FILTER
        help
          Provide stacktrace filter for fault-injection capabilities
 
-config LATENCYTOP
-       bool "Latency measuring infrastructure"
-       depends on DEBUG_KERNEL
-       depends on STACKTRACE_SUPPORT
-       depends on PROC_FS
-       select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM && !ARC && !X86
-       select KALLSYMS
-       select KALLSYMS_ALL
-       select STACKTRACE
-       select SCHEDSTATS
-       select SCHED_DEBUG
-       help
-         Enable this option if you want to use the LatencyTOP tool
-         to find out which userspace is blocking on what kernel operations.
+endmenu # "Kernel Testing and Coverage"
 
-source "kernel/trace/Kconfig"
+menu "Kernel Testing and Coverage"
 
-config PROVIDE_OHCI1394_DMA_INIT
-       bool "Remote debugging over FireWire early on boot"
-       depends on PCI && X86
+config ARCH_HAS_KCOV
+       bool
        help
-         If you want to debug problems which hang or crash the kernel early
-         on boot and the crashing machine has a FireWire port, you can use
-         this feature to remotely access the memory of the crashed machine
-         over FireWire. This employs remote DMA as part of the OHCI1394
-         specification which is now the standard for FireWire controllers.
+         An architecture should select this when it can successfully
+         build and run with CONFIG_KCOV. This typically requires
+         disabling instrumentation for some early boot code.
 
-         With remote DMA, you can monitor the printk buffer remotely using
-         firescope and access all memory below 4GB using fireproxy from gdb.
-         Even controlling a kernel debugger is possible using remote DMA.
+config CC_HAS_SANCOV_TRACE_PC
+       def_bool $(cc-option,-fsanitize-coverage=trace-pc)
 
-         Usage:
 
-         If ohci1394_dma=early is used as boot parameter, it will initialize
-         all OHCI1394 controllers which are found in the PCI config space.
+config KCOV
+       bool "Code coverage for fuzzing"
+       depends on ARCH_HAS_KCOV
+       depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
+       select DEBUG_FS
+       select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC
+       help
+         KCOV exposes kernel code coverage information in a form suitable
+         for coverage-guided fuzzing (randomized testing).
 
-         As all changes to the FireWire bus such as enabling and disabling
-         devices cause a bus reset and thereby disable remote DMA for all
-         devices, be sure to have the cable plugged and FireWire enabled on
-         the debugging host before booting the debug target for debugging.
+         If RANDOMIZE_BASE is enabled, PC values will not be stable across
+         different machines and across reboots. If you need stable PC values,
+         disable RANDOMIZE_BASE.
 
-         This code (~1k) is freed after boot. By then, the firewire stack
-         in charge of the OHCI-1394 controllers should be used instead.
+         For more details, see Documentation/dev-tools/kcov.rst.
 
-         See Documentation/debugging-via-ohci1394.txt for more information.
+config KCOV_ENABLE_COMPARISONS
+       bool "Enable comparison operands collection by KCOV"
+       depends on KCOV
+       depends on $(cc-option,-fsanitize-coverage=trace-cmp)
+       help
+         KCOV also exposes operands of every comparison in the instrumented
+         code along with operand sizes and PCs of the comparison instructions.
+         These operands can be used by fuzzing engines to improve the quality
+         of fuzzing coverage.
 
-source "lib/kunit/Kconfig"
+config KCOV_INSTRUMENT_ALL
+       bool "Instrument all code by default"
+       depends on KCOV
+       default y
+       help
+         If you are doing generic system call fuzzing (like e.g. syzkaller),
+         then you will want to instrument the whole kernel and you should
+         say y here. If you are doing more targeted fuzzing (like e.g.
+         filesystem fuzzing with AFL) then you will want to enable coverage
+         for more specific subsets of files, and should say n here.
 
 menuconfig RUNTIME_TESTING_MENU
        bool "Runtime Testing"