[PATCH v2 0/9] kconfig/hacking: make 'kernel hacking' menu better structurized

[PATCH v2 0/9] kconfig/hacking: make 'kernel hacking' menu better structurized

[Changbin Du]

This series is a trivial improvment for the layout of 'kernel hacking'
configuration menu. Now we have many items in it which makes takes
a little time to look up them since they are not well structurized yet.

Early discussion is here:
https://lkml.org/lkml/2019/9/1/39

This is a preview:

  │ ┌─────────────────────────────────────────────────────────────────────────┐ │  
  │ │        printk and dmesg options  --->                                   │ │  
  │ │        Compile-time checks and compiler options  --->                   │ │  
  │ │        Generic Kernel Debugging Instruments  --->                       │ │  
  │ │    -*- Kernel debugging                                                 │ │  
  │ │    [*]   Miscellaneous debug code                                       │ │  
  │ │        Memory Debugging  --->                                           │ │  
  │ │    [ ] Debug shared IRQ handlers                                        │ │  
  │ │        Debug Oops, Lockups and Hangs  --->                              │ │  
  │ │        Scheduler Debugging  --->                                        │ │  
  │ │    [*] Enable extra timekeeping sanity checking                         │ │  
  │ │        Lock Debugging (spinlocks, mutexes, etc...)  --->                │ │  
  │ │    -*- Stack backtrace support                                          │ │  
  │ │    [ ] Warn for all uses of unseeded randomness                         │ │  
  │ │    [ ] kobject debugging                                                │ │  
  │ │        Debug kernel data structures  --->                               │ │  
  │ │    [ ] Debug credential management                                      │ │  
  │ │        RCU Debugging  --->                                              │ │  
  │ │    [ ] Force round-robin CPU selection for unbound work items           │ │  
  │ │    [ ] Force extended block device numbers and spread them              │ │  
  │ │    [ ] Enable CPU hotplug state control                                 │ │  
  │ │    [*] Latency measuring infrastructure                                 │ │  
  │ │    [*] Tracers  --->                                                    │ │  
  │ │    [ ] Remote debugging over FireWire early on boot                     │ │  
  │ │    [*] Sample kernel code  --->                                         │ │  
  │ │    [*] Filter access to /dev/mem                                        │ │  
  │ │    [ ]   Filter I/O access to /dev/mem                                  │ │  
  │ │    [ ] Additional debug code for syzbot                                 │ │  
  │ │        x86 Debugging  --->                                              │ │  
  │ │        Kernel Testing and Coverage  --->                                │ │  
  │ │                                                                         │ │  
  │ │                                                                         │ │  
  │ └─────────────────────────────────────────────────────────────────────────┘ │  
  ├─────────────────────────────────────────────────────────────────────────────┤  
  │          <Select>    < Exit >    < Help >    < Save >    < Load >           │  
  └─────────────────────────────────────────────────────────────────────────────┘ 

v2:
  o rebase to linux-next.
  o move DEBUG_FS to 'Generic Kernel Debugging Instruments'
  o move DEBUG_NOTIFIERS to 'Debug kernel data structures'

Changbin Du (9):
  kconfig/hacking: Group sysrq/kgdb/ubsan into 'Generic Kernel Debugging
    Instruments'
  kconfig/hacking: Create submenu for arch special debugging options
  kconfig/hacking: Group kernel data structures debugging together
  kconfig/hacking: Move kernel testing and coverage options to same
    submenu
  kconfig/hacking: Move Oops into 'Lockups and Hangs'
  kconfig/hacking: Move SCHED_STACK_END_CHECK after DEBUG_STACK_USAGE
  kconfig/hacking: Create a submenu for scheduler debugging options
  kconfig/hacking: Move DEBUG_BUGVERBOSE to 'printk and dmesg options'
  kconfig/hacking: Move DEBUG_FS to 'Generic Kernel Debugging
    Instruments'

 lib/Kconfig.debug | 659 ++++++++++++++++++++++++----------------------
 1 file changed, 340 insertions(+), 319 deletions(-)

-- 
2.20.1

[PATCH v2 1/9] kconfig/hacking: Group sysrq/kgdb/ubsan into 'Generic Kernel Debugging Instruments'

[Changbin Du]

Group generic kernel debugging instruments sysrq/kgdb/ubsan together into
a new submenu.

Signed-off-by: Changbin Du <changbin.du@gmail.com>
---
 lib/Kconfig.debug | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 10023dbac8e4..bd3938483514 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -419,6 +419,8 @@ config DEBUG_FORCE_WEAK_PER_CPU
 
 endmenu # "Compiler options"
 
+menu "Generic Kernel Debugging Instruments"
+
 config MAGIC_SYSRQ
 	bool "Magic SysRq key"
 	depends on !UML
@@ -452,6 +454,12 @@ config MAGIC_SYSRQ_SERIAL
 	  This option allows you to decide whether you want to enable the
 	  magic SysRq key.
 
+source "lib/Kconfig.kgdb"
+
+source "lib/Kconfig.ubsan"
+
+endmenu
+
 config DEBUG_KERNEL
 	bool "Kernel debugging"
 	help
@@ -2111,10 +2119,6 @@ config BUG_ON_DATA_CORRUPTION
 
 source "samples/Kconfig"
 
-source "lib/Kconfig.kgdb"
-
-source "lib/Kconfig.ubsan"
-
 config ARCH_HAS_DEVMEM_IS_ALLOWED
 	bool
 
-- 
2.20.1

[PATCH v2 2/9] kconfig/hacking: Create submenu for arch special debugging options

[Changbin Du]

The arch special options are a little long, so create a submenu for them.

Signed-off-by: Changbin Du <changbin.du@gmail.com>
---
 lib/Kconfig.debug | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index bd3938483514..cc4d8e71ae81 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2164,6 +2164,10 @@ config DEBUG_AID_FOR_SYZBOT
        help
          This option is intended for testing by syzbot.
 
+menu "$(SRCARCH) Debugging"
+
 source "arch/$(SRCARCH)/Kconfig.debug"
 
+endmenu
+
 endmenu # Kernel hacking
-- 
2.20.1

[PATCH v2 3/9] kconfig/hacking: Group kernel data structures debugging together

[Changbin Du]

Group these similar runtime data structures verification options together.

Signed-off-by: Changbin Du <changbin.du@gmail.com>
---
 lib/Kconfig.debug | 24 ++++++++++++++----------
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index cc4d8e71ae81..92271898b029 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1375,6 +1375,8 @@ config DEBUG_BUGVERBOSE
 	  of the BUG call as well as the EIP and oops trace.  This aids
 	  debugging but costs about 70-100K of memory.
 
+menu "Debug kernel data structures"
+
 config DEBUG_LIST
 	bool "Debug linked list manipulation"
 	depends on DEBUG_KERNEL || BUG_ON_DATA_CORRUPTION
@@ -1414,6 +1416,18 @@ config DEBUG_NOTIFIERS
 	  This is a relatively cheap check but if you care about maximum
 	  performance, say N.
 
+config BUG_ON_DATA_CORRUPTION
+	bool "Trigger a BUG when data corruption is detected"
+	select DEBUG_LIST
+	help
+	  Select this option if the kernel should BUG when it encounters
+	  data corruption in kernel memory structures when they get checked
+	  for validity.
+
+	  If unsure, say N.
+
+endmenu
+
 config DEBUG_CREDENTIALS
 	bool "Debug credential management"
 	depends on DEBUG_KERNEL
@@ -2107,16 +2121,6 @@ config MEMTEST
 	        memtest=17, mean do 17 test patterns.
 	  If you are unsure how to answer this question, answer N.
 
-config BUG_ON_DATA_CORRUPTION
-	bool "Trigger a BUG when data corruption is detected"
-	select DEBUG_LIST
-	help
-	  Select this option if the kernel should BUG when it encounters
-	  data corruption in kernel memory structures when they get checked
-	  for validity.
-
-	  If unsure, say N.
-
 source "samples/Kconfig"
 
 config ARCH_HAS_DEVMEM_IS_ALLOWED
-- 
2.20.1

[PATCH v2 4/9] kconfig/hacking: Move kernel testing and coverage options to same submenu

[Changbin Du]

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

Signed-off-by: Changbin Du <changbin.du@gmail.com>
---
 lib/Kconfig.debug | 497 +++++++++++++++++++++++-----------------------
 1 file changed, 251 insertions(+), 246 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 92271898b029..7b3552531d02 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -784,53 +784,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
@@ -1500,164 +1453,6 @@ config CPU_HOTPLUG_STATE_CONTROL
 
 	  Say N if your are unsure.
 
-config NOTIFIER_ERROR_INJECTION
-	tristate "Notifier error injection"
-	depends on DEBUG_KERNEL
-	select DEBUG_FS
-	help
-	  This option provides the ability to inject artificial errors to
-	  specified notifier chain callbacks. It is useful to test the error
-	  handling of notifier call chain failures.
-
-	  Say N if unsure.
-
-config PM_NOTIFIER_ERROR_INJECT
-	tristate "PM notifier error injection module"
-	depends on PM && NOTIFIER_ERROR_INJECTION
-	default m if PM_DEBUG
-	help
-	  This option provides the ability to inject artificial errors to
-	  PM notifier chain callbacks.  It is controlled through debugfs
-	  interface /sys/kernel/debug/notifier-error-inject/pm
-
-	  If the notifier call chain should be failed with some events
-	  notified, write the error code to "actions/<notifier event>/error".
-
-	  Example: Inject PM suspend error (-12 = -ENOMEM)
-
-	  # cd /sys/kernel/debug/notifier-error-inject/pm/
-	  # echo -12 > actions/PM_SUSPEND_PREPARE/error
-	  # echo mem > /sys/power/state
-	  bash: echo: write error: Cannot allocate memory
-
-	  To compile this code as a module, choose M here: the module will
-	  be called pm-notifier-error-inject.
-
-	  If unsure, say N.
-
-config OF_RECONFIG_NOTIFIER_ERROR_INJECT
-	tristate "OF reconfig notifier error injection module"
-	depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION
-	help
-	  This option provides the ability to inject artificial errors to
-	  OF reconfig notifier chain callbacks.  It is controlled
-	  through debugfs interface under
-	  /sys/kernel/debug/notifier-error-inject/OF-reconfig/
-
-	  If the notifier call chain should be failed with some events
-	  notified, write the error code to "actions/<notifier event>/error".
-
-	  To compile this code as a module, choose M here: the module will
-	  be called of-reconfig-notifier-error-inject.
-
-	  If unsure, say N.
-
-config NETDEV_NOTIFIER_ERROR_INJECT
-	tristate "Netdev notifier error injection module"
-	depends on NET && NOTIFIER_ERROR_INJECTION
-	help
-	  This option provides the ability to inject artificial errors to
-	  netdevice notifier chain callbacks.  It is controlled through debugfs
-	  interface /sys/kernel/debug/notifier-error-inject/netdev
-
-	  If the notifier call chain should be failed with some events
-	  notified, write the error code to "actions/<notifier event>/error".
-
-	  Example: Inject netdevice mtu change error (-22 = -EINVAL)
-
-	  # cd /sys/kernel/debug/notifier-error-inject/netdev
-	  # echo -22 > actions/NETDEV_CHANGEMTU/error
-	  # ip link set eth0 mtu 1024
-	  RTNETLINK answers: Invalid argument
-
-	  To compile this code as a module, choose M here: the module will
-	  be called netdev-notifier-error-inject.
-
-	  If unsure, say N.
-
-config FUNCTION_ERROR_INJECTION
-	def_bool y
-	depends on HAVE_FUNCTION_ERROR_INJECTION && KPROBES
-
-config FAULT_INJECTION
-	bool "Fault-injection framework"
-	depends on DEBUG_KERNEL
-	help
-	  Provide fault-injection framework.
-	  For more details, see Documentation/fault-injection/.
-
-config FAILSLAB
-	bool "Fault-injection capability for kmalloc"
-	depends on FAULT_INJECTION
-	depends on SLAB || SLUB
-	help
-	  Provide fault-injection capability for kmalloc.
-
-config FAIL_PAGE_ALLOC
-	bool "Fault-injection capabilitiy for alloc_pages()"
-	depends on FAULT_INJECTION
-	help
-	  Provide fault-injection capability for alloc_pages().
-
-config FAIL_MAKE_REQUEST
-	bool "Fault-injection capability for disk IO"
-	depends on FAULT_INJECTION && BLOCK
-	help
-	  Provide fault-injection capability for disk IO.
-
-config FAIL_IO_TIMEOUT
-	bool "Fault-injection capability for faking disk interrupts"
-	depends on FAULT_INJECTION && BLOCK
-	help
-	  Provide fault-injection capability on end IO handling. This
-	  will make the block layer "forget" an interrupt as configured,
-	  thus exercising the error handling.
-
-	  Only works with drivers that use the generic timeout handling,
-	  for others it wont do anything.
-
-config FAIL_FUTEX
-	bool "Fault-injection capability for futexes"
-	select DEBUG_FS
-	depends on FAULT_INJECTION && FUTEX
-	help
-	  Provide fault-injection capability for futexes.
-
-config FAULT_INJECTION_DEBUG_FS
-	bool "Debugfs entries for fault-injection capabilities"
-	depends on FAULT_INJECTION && SYSFS && DEBUG_FS
-	help
-	  Enable configuration of fault-injection capabilities via debugfs.
-
-config FAIL_FUNCTION
-	bool "Fault-injection capability for functions"
-	depends on FAULT_INJECTION_DEBUG_FS && FUNCTION_ERROR_INJECTION
-	help
-	  Provide function-based fault-injection capability.
-	  This will allow you to override a specific function with a return
-	  with given return value. As a result, function caller will see
-	  an error value and have to handle it. This is useful to test the
-	  error handling in various subsystems.
-
-config FAIL_MMC_REQUEST
-	bool "Fault-injection capability for MMC IO"
-	depends on FAULT_INJECTION_DEBUG_FS && MMC
-	help
-	  Provide fault-injection capability for MMC IO.
-	  This will make the mmc core return data errors. This is
-	  useful to test the error handling in the mmc block device
-	  and to test how the mmc host driver handles retries from
-	  the block device.
-
-config FAULT_INJECTION_STACKTRACE_FILTER
-	bool "stacktrace filter for fault-injection capabilities"
-	depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT
-	depends on !X86_64
-	select STACKTRACE
-	select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM && !ARC && !X86
-	help
-	  Provide stacktrace filter for fault-injection capabilities
-
 config LATENCYTOP
 	bool "Latency measuring infrastructure"
 	depends on DEBUG_KERNEL
@@ -1704,6 +1499,109 @@ config PROVIDE_OHCI1394_DMA_INIT
 
 	  See Documentation/debugging-via-ohci1394.txt for more information.
 
+source "samples/Kconfig"
+
+config ARCH_HAS_DEVMEM_IS_ALLOWED
+	bool
+
+config STRICT_DEVMEM
+	bool "Filter access to /dev/mem"
+	depends on MMU && DEVMEM
+	depends on ARCH_HAS_DEVMEM_IS_ALLOWED
+	default y if PPC || X86 || ARM64
+	---help---
+	  If this option is disabled, you allow userspace (root) access to all
+	  of memory, including kernel and userspace memory. Accidental
+	  access to this is obviously disastrous, but specific access can
+	  be used by people debugging the kernel. Note that with PAT support
+	  enabled, even in this case there are restrictions on /dev/mem
+	  use due to the cache aliasing requirements.
+
+	  If this option is switched on, and IO_STRICT_DEVMEM=n, the /dev/mem
+	  file only allows userspace access to PCI space and the BIOS code and
+	  data regions.  This is sufficient for dosemu and X and all common
+	  users of /dev/mem.
+
+	  If in doubt, say Y.
+
+config IO_STRICT_DEVMEM
+	bool "Filter I/O access to /dev/mem"
+	depends on STRICT_DEVMEM
+	---help---
+	  If this option is disabled, you allow userspace (root) access to all
+	  io-memory regardless of whether a driver is actively using that
+	  range.  Accidental access to this is obviously disastrous, but
+	  specific access can be used by people debugging kernel drivers.
+
+	  If this option is switched on, the /dev/mem file only allows
+	  userspace access to *idle* io-memory ranges (see /proc/iomem) This
+	  may break traditional users of /dev/mem (dosemu, legacy X, etc...)
+	  if the driver using a given range cannot be disabled.
+
+	  If in doubt, say Y.
+
+config DEBUG_AID_FOR_SYZBOT
+       bool "Additional debug code for syzbot"
+       default n
+       help
+         This option is intended for testing by syzbot.
+
+menu "$(SRCARCH) Debugging"
+
+source "arch/$(SRCARCH)/Kconfig.debug"
+
+endmenu
+
+menu "Kernel Testing and Coverage"
+
+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.
+
 menuconfig RUNTIME_TESTING_MENU
 	bool "Runtime Testing"
 	def_bool y
@@ -2121,57 +2019,164 @@ config MEMTEST
 	        memtest=17, mean do 17 test patterns.
 	  If you are unsure how to answer this question, answer N.
 
-source "samples/Kconfig"
+config NOTIFIER_ERROR_INJECTION
+	tristate "Notifier error injection"
+	depends on DEBUG_KERNEL
+	select DEBUG_FS
+	help
+	  This option provides the ability to inject artificial errors to
+	  specified notifier chain callbacks. It is useful to test the error
+	  handling of notifier call chain failures.
 
-config ARCH_HAS_DEVMEM_IS_ALLOWED
-	bool
+	  Say N if unsure.
 
-config STRICT_DEVMEM
-	bool "Filter access to /dev/mem"
-	depends on MMU && DEVMEM
-	depends on ARCH_HAS_DEVMEM_IS_ALLOWED
-	default y if PPC || X86 || ARM64
-	---help---
-	  If this option is disabled, you allow userspace (root) access to all
-	  of memory, including kernel and userspace memory. Accidental
-	  access to this is obviously disastrous, but specific access can
-	  be used by people debugging the kernel. Note that with PAT support
-	  enabled, even in this case there are restrictions on /dev/mem
-	  use due to the cache aliasing requirements.
+config PM_NOTIFIER_ERROR_INJECT
+	tristate "PM notifier error injection module"
+	depends on PM && NOTIFIER_ERROR_INJECTION
+	default m if PM_DEBUG
+	help
+	  This option provides the ability to inject artificial errors to
+	  PM notifier chain callbacks.  It is controlled through debugfs
+	  interface /sys/kernel/debug/notifier-error-inject/pm
 
-	  If this option is switched on, and IO_STRICT_DEVMEM=n, the /dev/mem
-	  file only allows userspace access to PCI space and the BIOS code and
-	  data regions.  This is sufficient for dosemu and X and all common
-	  users of /dev/mem.
+	  If the notifier call chain should be failed with some events
+	  notified, write the error code to "actions/<notifier event>/error".
 
-	  If in doubt, say Y.
+	  Example: Inject PM suspend error (-12 = -ENOMEM)
 
-config IO_STRICT_DEVMEM
-	bool "Filter I/O access to /dev/mem"
-	depends on STRICT_DEVMEM
-	---help---
-	  If this option is disabled, you allow userspace (root) access to all
-	  io-memory regardless of whether a driver is actively using that
-	  range.  Accidental access to this is obviously disastrous, but
-	  specific access can be used by people debugging kernel drivers.
+	  # cd /sys/kernel/debug/notifier-error-inject/pm/
+	  # echo -12 > actions/PM_SUSPEND_PREPARE/error
+	  # echo mem > /sys/power/state
+	  bash: echo: write error: Cannot allocate memory
 
-	  If this option is switched on, the /dev/mem file only allows
-	  userspace access to *idle* io-memory ranges (see /proc/iomem) This
-	  may break traditional users of /dev/mem (dosemu, legacy X, etc...)
-	  if the driver using a given range cannot be disabled.
+	  To compile this code as a module, choose M here: the module will
+	  be called pm-notifier-error-inject.
 
-	  If in doubt, say Y.
+	  If unsure, say N.
 
-config DEBUG_AID_FOR_SYZBOT
-       bool "Additional debug code for syzbot"
-       default n
-       help
-         This option is intended for testing by syzbot.
+config OF_RECONFIG_NOTIFIER_ERROR_INJECT
+	tristate "OF reconfig notifier error injection module"
+	depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION
+	help
+	  This option provides the ability to inject artificial errors to
+	  OF reconfig notifier chain callbacks.  It is controlled
+	  through debugfs interface under
+	  /sys/kernel/debug/notifier-error-inject/OF-reconfig/
 
-menu "$(SRCARCH) Debugging"
+	  If the notifier call chain should be failed with some events
+	  notified, write the error code to "actions/<notifier event>/error".
 
-source "arch/$(SRCARCH)/Kconfig.debug"
+	  To compile this code as a module, choose M here: the module will
+	  be called of-reconfig-notifier-error-inject.
 
-endmenu
+	  If unsure, say N.
+
+config NETDEV_NOTIFIER_ERROR_INJECT
+	tristate "Netdev notifier error injection module"
+	depends on NET && NOTIFIER_ERROR_INJECTION
+	help
+	  This option provides the ability to inject artificial errors to
+	  netdevice notifier chain callbacks.  It is controlled through debugfs
+	  interface /sys/kernel/debug/notifier-error-inject/netdev
+
+	  If the notifier call chain should be failed with some events
+	  notified, write the error code to "actions/<notifier event>/error".
+
+	  Example: Inject netdevice mtu change error (-22 = -EINVAL)
+
+	  # cd /sys/kernel/debug/notifier-error-inject/netdev
+	  # echo -22 > actions/NETDEV_CHANGEMTU/error
+	  # ip link set eth0 mtu 1024
+	  RTNETLINK answers: Invalid argument
+
+	  To compile this code as a module, choose M here: the module will
+	  be called netdev-notifier-error-inject.
+
+	  If unsure, say N.
+
+config FUNCTION_ERROR_INJECTION
+	def_bool y
+	depends on HAVE_FUNCTION_ERROR_INJECTION && KPROBES
+
+config FAULT_INJECTION
+	bool "Fault-injection framework"
+	depends on DEBUG_KERNEL
+	help
+	  Provide fault-injection framework.
+	  For more details, see Documentation/fault-injection/.
+
+config FAILSLAB
+	bool "Fault-injection capability for kmalloc"
+	depends on FAULT_INJECTION
+	depends on SLAB || SLUB
+	help
+	  Provide fault-injection capability for kmalloc.
+
+config FAIL_PAGE_ALLOC
+	bool "Fault-injection capabilitiy for alloc_pages()"
+	depends on FAULT_INJECTION
+	help
+	  Provide fault-injection capability for alloc_pages().
+
+config FAIL_MAKE_REQUEST
+	bool "Fault-injection capability for disk IO"
+	depends on FAULT_INJECTION && BLOCK
+	help
+	  Provide fault-injection capability for disk IO.
+
+config FAIL_IO_TIMEOUT
+	bool "Fault-injection capability for faking disk interrupts"
+	depends on FAULT_INJECTION && BLOCK
+	help
+	  Provide fault-injection capability on end IO handling. This
+	  will make the block layer "forget" an interrupt as configured,
+	  thus exercising the error handling.
+
+	  Only works with drivers that use the generic timeout handling,
+	  for others it wont do anything.
+
+config FAIL_FUTEX
+	bool "Fault-injection capability for futexes"
+	select DEBUG_FS
+	depends on FAULT_INJECTION && FUTEX
+	help
+	  Provide fault-injection capability for futexes.
+
+config FAULT_INJECTION_DEBUG_FS
+	bool "Debugfs entries for fault-injection capabilities"
+	depends on FAULT_INJECTION && SYSFS && DEBUG_FS
+	help
+	  Enable configuration of fault-injection capabilities via debugfs.
+
+config FAIL_FUNCTION
+	bool "Fault-injection capability for functions"
+	depends on FAULT_INJECTION_DEBUG_FS && FUNCTION_ERROR_INJECTION
+	help
+	  Provide function-based fault-injection capability.
+	  This will allow you to override a specific function with a return
+	  with given return value. As a result, function caller will see
+	  an error value and have to handle it. This is useful to test the
+	  error handling in various subsystems.
+
+config FAIL_MMC_REQUEST
+	bool "Fault-injection capability for MMC IO"
+	depends on FAULT_INJECTION_DEBUG_FS && MMC
+	help
+	  Provide fault-injection capability for MMC IO.
+	  This will make the mmc core return data errors. This is
+	  useful to test the error handling in the mmc block device
+	  and to test how the mmc host driver handles retries from
+	  the block device.
+
+config FAULT_INJECTION_STACKTRACE_FILTER
+	bool "stacktrace filter for fault-injection capabilities"
+	depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT
+	depends on !X86_64
+	select STACKTRACE
+	select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM && !ARC && !X86
+	help
+	  Provide stacktrace filter for fault-injection capabilities
+
+endmenu # "Kernel Testing and Coverage"
 
 endmenu # Kernel hacking
-- 
2.20.1

[PATCH v2 5/9] kconfig/hacking: Move Oops into 'Lockups and Hangs'

[Changbin Du]

They are similar options so place them together.

Signed-off-by: Changbin Du <changbin.du@gmail.com>
---
 lib/Kconfig.debug | 58 +++++++++++++++++++++++------------------------
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 7b3552531d02..1385e17122a1 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -793,7 +793,35 @@ config DEBUG_SHIRQ
 	  Drivers ought to be able to handle interrupts coming in at those
 	  points; some don't and need to be caught.
 
-menu "Debug Lockups and Hangs"
+menu "Debug Oops, Lockups and Hangs"
+
+config PANIC_ON_OOPS
+	bool "Panic on Oops"
+	help
+	  Say Y here to enable the kernel to panic when it oopses. This
+	  has the same effect as setting oops=panic on the kernel command
+	  line.
+
+	  This feature is useful to ensure that the kernel does not do
+	  anything erroneous after an oops which could result in data
+	  corruption or other issues.
+
+	  Say N if unsure.
+
+config PANIC_ON_OOPS_VALUE
+	int
+	range 0 1
+	default 0 if !PANIC_ON_OOPS
+	default 1 if PANIC_ON_OOPS
+
+config PANIC_TIMEOUT
+	int "panic timeout"
+	default 0
+	help
+	  Set the timeout value (in seconds) until a reboot occurs when the
+	  the kernel panics. If n = 0, then we wait forever. A timeout
+	  value n > 0 will wait n seconds before rebooting, while a timeout
+	  value n < 0 will reboot immediately.
 
 config LOCKUP_DETECTOR
 	bool
@@ -951,34 +979,6 @@ config WQ_WATCHDOG
 
 endmenu # "Debug lockups and hangs"
 
-config PANIC_ON_OOPS
-	bool "Panic on Oops"
-	help
-	  Say Y here to enable the kernel to panic when it oopses. This
-	  has the same effect as setting oops=panic on the kernel command
-	  line.
-
-	  This feature is useful to ensure that the kernel does not do
-	  anything erroneous after an oops which could result in data
-	  corruption or other issues.
-
-	  Say N if unsure.
-
-config PANIC_ON_OOPS_VALUE
-	int
-	range 0 1
-	default 0 if !PANIC_ON_OOPS
-	default 1 if PANIC_ON_OOPS
-
-config PANIC_TIMEOUT
-	int "panic timeout"
-	default 0
-	help
-	  Set the timeout value (in seconds) until a reboot occurs when the
-	  the kernel panics. If n = 0, then we wait forever. A timeout
-	  value n > 0 will wait n seconds before rebooting, while a timeout
-	  value n < 0 will reboot immediately.
-
 config SCHED_DEBUG
 	bool "Collect scheduler debugging info"
 	depends on DEBUG_KERNEL && PROC_FS
-- 
2.20.1

[PATCH v2 6/9] kconfig/hacking: Move SCHED_STACK_END_CHECK after DEBUG_STACK_USAGE

[Changbin Du]

They are both memory debug options to debug kernel stack issues.

Signed-off-by: Changbin Du <changbin.du@gmail.com>
---
 lib/Kconfig.debug | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 1385e17122a1..ce545bb80ea2 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -652,6 +652,18 @@ config DEBUG_STACK_USAGE
 
 	  This option will slow down process creation somewhat.
 
+config SCHED_STACK_END_CHECK
+	bool "Detect stack corruption on calls to schedule()"
+	depends on DEBUG_KERNEL
+	default n
+	help
+	  This option checks for a stack overrun on calls to schedule().
+	  If the stack end location is found to be over written always panic as
+	  the content of the corrupted region can no longer be trusted.
+	  This is to ensure no erroneous behaviour occurs which could result in
+	  data corruption or a sporadic crash at a later stage once the region
+	  is examined. The runtime overhead introduced is minimal.
+
 config DEBUG_VM
 	bool "Debug VM"
 	depends on DEBUG_KERNEL
@@ -1005,18 +1017,6 @@ config SCHEDSTATS
 	  application, you can say N to avoid the very slight overhead
 	  this adds.
 
-config SCHED_STACK_END_CHECK
-	bool "Detect stack corruption on calls to schedule()"
-	depends on DEBUG_KERNEL
-	default n
-	help
-	  This option checks for a stack overrun on calls to schedule().
-	  If the stack end location is found to be over written always panic as
-	  the content of the corrupted region can no longer be trusted.
-	  This is to ensure no erroneous behaviour occurs which could result in
-	  data corruption or a sporadic crash at a later stage once the region
-	  is examined. The runtime overhead introduced is minimal.
-
 config DEBUG_TIMEKEEPING
 	bool "Enable extra timekeeping sanity checking"
 	help
-- 
2.20.1

[PATCH v2 7/9] kconfig/hacking: Create a submenu for scheduler debugging options

[Changbin Du]

Create a submenu 'Scheduler Debugging' for scheduler debugging options.

Signed-off-by: Changbin Du <changbin.du@gmail.com>
---
 lib/Kconfig.debug | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index ce545bb80ea2..ce891713c914 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -991,6 +991,8 @@ config WQ_WATCHDOG
 
 endmenu # "Debug lockups and hangs"
 
+menu "Scheduler Debugging"
+
 config SCHED_DEBUG
 	bool "Collect scheduler debugging info"
 	depends on DEBUG_KERNEL && PROC_FS
@@ -1017,6 +1019,8 @@ config SCHEDSTATS
 	  application, you can say N to avoid the very slight overhead
 	  this adds.
 
+endmenu
+
 config DEBUG_TIMEKEEPING
 	bool "Enable extra timekeeping sanity checking"
 	help
-- 
2.20.1

[PATCH v2 8/9] kconfig/hacking: Move DEBUG_BUGVERBOSE to 'printk and dmesg options'

[Changbin Du]

I think DEBUG_BUGVERBOSE is a dmesg option which gives more debug info
to dmesg.

Signed-off-by: Changbin Du <changbin.du@gmail.com>
---
 lib/Kconfig.debug | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index ce891713c914..ceefe0c1e78b 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -164,6 +164,15 @@ config DYNAMIC_DEBUG
 	  See Documentation/admin-guide/dynamic-debug-howto.rst for additional
 	  information.
 
+config DEBUG_BUGVERBOSE
+	bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
+	depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
+	default y
+	help
+	  Say Y here to make BUG() panics output the file name and line number
+	  of the BUG call as well as the EIP and oops trace.  This aids
+	  debugging but costs about 70-100K of memory.
+
 endmenu # "printk and dmesg options"
 
 menu "Compile-time checks and compiler options"
@@ -1323,15 +1332,6 @@ config DEBUG_KOBJECT_RELEASE
 config HAVE_DEBUG_BUGVERBOSE
 	bool
 
-config DEBUG_BUGVERBOSE
-	bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
-	depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
-	default y
-	help
-	  Say Y here to make BUG() panics output the file name and line number
-	  of the BUG call as well as the EIP and oops trace.  This aids
-	  debugging but costs about 70-100K of memory.
-
 menu "Debug kernel data structures"
 
 config DEBUG_LIST
-- 
2.20.1

[PATCH v2 9/9] kconfig/hacking: Move DEBUG_FS to 'Generic Kernel Debugging Instruments'

[Changbin Du]

DEBUG_FS does not belong to 'Compile-time checks and compiler options'.

Cc: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Changbin Du <changbin.du@gmail.com>
---
 lib/Kconfig.debug | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index ceefe0c1e78b..09e82676e59c 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -302,18 +302,6 @@ config UNUSED_SYMBOLS
 	  you really need it, and what the merge plan to the mainline kernel for
 	  your module is.
 
-config DEBUG_FS
-	bool "Debug Filesystem"
-	help
-	  debugfs is a virtual file system that kernel developers use to put
-	  debugging files into.  Enable this option to be able to read and
-	  write to these files.
-
-	  For detailed documentation on the debugfs API, see
-	  Documentation/filesystems/.
-
-	  If unsure, say N.
-
 config HEADERS_INSTALL
 	bool "Install uapi headers to usr/include"
 	depends on !UML
@@ -463,6 +451,18 @@ config MAGIC_SYSRQ_SERIAL
 	  This option allows you to decide whether you want to enable the
 	  magic SysRq key.
 
+config DEBUG_FS
+	bool "Debug Filesystem"
+	help
+	  debugfs is a virtual file system that kernel developers use to put
+	  debugging files into.  Enable this option to be able to read and
+	  write to these files.
+
+	  For detailed documentation on the debugfs API, see
+	  Documentation/filesystems/.
+
+	  If unsure, say N.
+
 source "lib/Kconfig.kgdb"
 
 source "lib/Kconfig.ubsan"
-- 
2.20.1

Re: [PATCH v2 0/9] kconfig/hacking: make 'kernel hacking' menu better structurized

[Masahiro Yamada]

Hi.

On Mon, Sep 9, 2019 at 11:18 PM Changbin Du <changbin.du@gmail.com> wrote:
>
> This series is a trivial improvment for the layout of 'kernel hacking'
> configuration menu. Now we have many items in it which makes takes
> a little time to look up them since they are not well structurized yet.


Could you please change the subject prefix "kconfig/hacking:" ?
("hacking:" , "debug:" or whatever, but no "kconfig")

I just opened this thread just in case it might be related to kconfig,
but it was not.

Thanks.






> Early discussion is here:
> https://lkml.org/lkml/2019/9/1/39
>
> This is a preview:
>
>   │ ┌─────────────────────────────────────────────────────────────────────────┐ │
>   │ │        printk and dmesg options  --->                                   │ │
>   │ │        Compile-time checks and compiler options  --->                   │ │
>   │ │        Generic Kernel Debugging Instruments  --->                       │ │
>   │ │    -*- Kernel debugging                                                 │ │
>   │ │    [*]   Miscellaneous debug code                                       │ │
>   │ │        Memory Debugging  --->                                           │ │
>   │ │    [ ] Debug shared IRQ handlers                                        │ │
>   │ │        Debug Oops, Lockups and Hangs  --->                              │ │
>   │ │        Scheduler Debugging  --->                                        │ │
>   │ │    [*] Enable extra timekeeping sanity checking                         │ │
>   │ │        Lock Debugging (spinlocks, mutexes, etc...)  --->                │ │
>   │ │    -*- Stack backtrace support                                          │ │
>   │ │    [ ] Warn for all uses of unseeded randomness                         │ │
>   │ │    [ ] kobject debugging                                                │ │
>   │ │        Debug kernel data structures  --->                               │ │
>   │ │    [ ] Debug credential management                                      │ │
>   │ │        RCU Debugging  --->                                              │ │
>   │ │    [ ] Force round-robin CPU selection for unbound work items           │ │
>   │ │    [ ] Force extended block device numbers and spread them              │ │
>   │ │    [ ] Enable CPU hotplug state control                                 │ │
>   │ │    [*] Latency measuring infrastructure                                 │ │
>   │ │    [*] Tracers  --->                                                    │ │
>   │ │    [ ] Remote debugging over FireWire early on boot                     │ │
>   │ │    [*] Sample kernel code  --->                                         │ │
>   │ │    [*] Filter access to /dev/mem                                        │ │
>   │ │    [ ]   Filter I/O access to /dev/mem                                  │ │
>   │ │    [ ] Additional debug code for syzbot                                 │ │
>   │ │        x86 Debugging  --->                                              │ │
>   │ │        Kernel Testing and Coverage  --->                                │ │
>   │ │                                                                         │ │
>   │ │                                                                         │ │
>   │ └─────────────────────────────────────────────────────────────────────────┘ │
>   ├─────────────────────────────────────────────────────────────────────────────┤
>   │          <Select>    < Exit >    < Help >    < Save >    < Load >           │
>   └─────────────────────────────────────────────────────────────────────────────┘
>
> v2:
>   o rebase to linux-next.
>   o move DEBUG_FS to 'Generic Kernel Debugging Instruments'
>   o move DEBUG_NOTIFIERS to 'Debug kernel data structures'
>
> Changbin Du (9):
>   kconfig/hacking: Group sysrq/kgdb/ubsan into 'Generic Kernel Debugging
>     Instruments'
>   kconfig/hacking: Create submenu for arch special debugging options
>   kconfig/hacking: Group kernel data structures debugging together
>   kconfig/hacking: Move kernel testing and coverage options to same
>     submenu
>   kconfig/hacking: Move Oops into 'Lockups and Hangs'
>   kconfig/hacking: Move SCHED_STACK_END_CHECK after DEBUG_STACK_USAGE
>   kconfig/hacking: Create a submenu for scheduler debugging options
>   kconfig/hacking: Move DEBUG_BUGVERBOSE to 'printk and dmesg options'
>   kconfig/hacking: Move DEBUG_FS to 'Generic Kernel Debugging
>     Instruments'
>
>  lib/Kconfig.debug | 659 ++++++++++++++++++++++++----------------------
>  1 file changed, 340 insertions(+), 319 deletions(-)
>
> --
> 2.20.1
>


--
Best Regards
Masahiro Yamada

Re: [PATCH v2 0/9] kconfig/hacking: make 'kernel hacking' menu better structurized

[Changbin Du]

On Mon, Sep 09, 2019 at 11:31:10PM +0900, Masahiro Yamada wrote:
> Hi.
> 
> On Mon, Sep 9, 2019 at 11:18 PM Changbin Du <changbin.du@gmail.com> wrote:
> >
> > This series is a trivial improvment for the layout of 'kernel hacking'
> > configuration menu. Now we have many items in it which makes takes
> > a little time to look up them since they are not well structurized yet.
> 
> 
> Could you please change the subject prefix "kconfig/hacking:" ?
> ("hacking:" , "debug:" or whatever, but no "kconfig")
>
sure, I pick 'hacking'.

> I just opened this thread just in case it might be related to kconfig,
> but it was not.
> 
> Thanks.
> 
> 
> 
> 
> 
> 
> > Early discussion is here:
> > https://lkml.org/lkml/2019/9/1/39
> >
> > This is a preview:
> >
> >   │ ┌─────────────────────────────────────────────────────────────────────────┐ │
> >   │ │        printk and dmesg options  --->                                   │ │
> >   │ │        Compile-time checks and compiler options  --->                   │ │
> >   │ │        Generic Kernel Debugging Instruments  --->                       │ │
> >   │ │    -*- Kernel debugging                                                 │ │
> >   │ │    [*]   Miscellaneous debug code                                       │ │
> >   │ │        Memory Debugging  --->                                           │ │
> >   │ │    [ ] Debug shared IRQ handlers                                        │ │
> >   │ │        Debug Oops, Lockups and Hangs  --->                              │ │
> >   │ │        Scheduler Debugging  --->                                        │ │
> >   │ │    [*] Enable extra timekeeping sanity checking                         │ │
> >   │ │        Lock Debugging (spinlocks, mutexes, etc...)  --->                │ │
> >   │ │    -*- Stack backtrace support                                          │ │
> >   │ │    [ ] Warn for all uses of unseeded randomness                         │ │
> >   │ │    [ ] kobject debugging                                                │ │
> >   │ │        Debug kernel data structures  --->                               │ │
> >   │ │    [ ] Debug credential management                                      │ │
> >   │ │        RCU Debugging  --->                                              │ │
> >   │ │    [ ] Force round-robin CPU selection for unbound work items           │ │
> >   │ │    [ ] Force extended block device numbers and spread them              │ │
> >   │ │    [ ] Enable CPU hotplug state control                                 │ │
> >   │ │    [*] Latency measuring infrastructure                                 │ │
> >   │ │    [*] Tracers  --->                                                    │ │
> >   │ │    [ ] Remote debugging over FireWire early on boot                     │ │
> >   │ │    [*] Sample kernel code  --->                                         │ │
> >   │ │    [*] Filter access to /dev/mem                                        │ │
> >   │ │    [ ]   Filter I/O access to /dev/mem                                  │ │
> >   │ │    [ ] Additional debug code for syzbot                                 │ │
> >   │ │        x86 Debugging  --->                                              │ │
> >   │ │        Kernel Testing and Coverage  --->                                │ │
> >   │ │                                                                         │ │
> >   │ │                                                                         │ │
> >   │ └─────────────────────────────────────────────────────────────────────────┘ │
> >   ├─────────────────────────────────────────────────────────────────────────────┤
> >   │          <Select>    < Exit >    < Help >    < Save >    < Load >           │
> >   └─────────────────────────────────────────────────────────────────────────────┘
> >
> > v2:
> >   o rebase to linux-next.
> >   o move DEBUG_FS to 'Generic Kernel Debugging Instruments'
> >   o move DEBUG_NOTIFIERS to 'Debug kernel data structures'
> >
> > Changbin Du (9):
> >   kconfig/hacking: Group sysrq/kgdb/ubsan into 'Generic Kernel Debugging
> >     Instruments'
> >   kconfig/hacking: Create submenu for arch special debugging options
> >   kconfig/hacking: Group kernel data structures debugging together
> >   kconfig/hacking: Move kernel testing and coverage options to same
> >     submenu
> >   kconfig/hacking: Move Oops into 'Lockups and Hangs'
> >   kconfig/hacking: Move SCHED_STACK_END_CHECK after DEBUG_STACK_USAGE
> >   kconfig/hacking: Create a submenu for scheduler debugging options
> >   kconfig/hacking: Move DEBUG_BUGVERBOSE to 'printk and dmesg options'
> >   kconfig/hacking: Move DEBUG_FS to 'Generic Kernel Debugging
> >     Instruments'
> >
> >  lib/Kconfig.debug | 659 ++++++++++++++++++++++++----------------------
> >  1 file changed, 340 insertions(+), 319 deletions(-)
> >
> > --
> > 2.20.1
> >
> 
> 
> --
> Best Regards
> Masahiro Yamada

-- 
Cheers,
Changbin Du