Commit 6dc517a3 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge branch 'akpm' (patches from Andrew) 

Merge misc Kconfig updates from Andrew Morton:
 "A number of changes to Kconfig files under lib/ from Changbin Du and
  Krzysztof Kozlowski"

* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
  lib/: fix Kconfig indentation
  kernel-hacking: move DEBUG_FS to 'Generic Kernel Debugging Instruments'
  kernel-hacking: move DEBUG_BUGVERBOSE to 'printk and dmesg options'
  kernel-hacking: create a submenu for scheduler debugging options
  kernel-hacking: move SCHED_STACK_END_CHECK after DEBUG_STACK_USAGE
  kernel-hacking: move Oops into 'Lockups and Hangs'
  kernel-hacking: move kernel testing and coverage options to same submenu
  kernel-hacking: group kernel data structures debugging together
  kernel-hacking: create submenu for arch special debugging options
  kernel-hacking: group sysrq/kgdb/ubsan into 'Generic Kernel Debugging Instruments'
parents 85190d15 68d4b3df

lib/Kconfig.debug

+194 −173
Original line number Diff line number Diff line
@@ -173,6 +173,15 @@ config SYMBOLIC_ERRNAME 
	  of the number 28. It makes the kernel image slightly larger

	  (about 3KB), but can make the kernel logs easier to read.



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"
@@ -286,18 +295,6 @@ config READABLE_ASM 
	  to keep kernel developers who have to stare a lot at assembler listings

	  sane.



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
@@ -399,6 +396,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
@@ -432,6 +431,24 @@ 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"



endmenu



config DEBUG_KERNEL

	bool "Kernel debugging"

	help
@@ -624,6 +641,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
@@ -756,53 +785,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
@@ -812,7 +794,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
@@ -970,33 +980,7 @@ 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.

menu "Scheduler Debugging"



config SCHED_DEBUG

	bool "Collect scheduler debugging info"
@@ -1024,17 +1008,7 @@ 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.

endmenu



config DEBUG_TIMEKEEPING

	bool "Enable extra timekeeping sanity checking"
@@ -1338,14 +1312,7 @@ 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

	bool "Debug linked list manipulation"
@@ -1386,6 +1353,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
@@ -1458,6 +1437,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
@@ -1616,53 +1643,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"
@@ -2099,22 +2130,8 @@ 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"



source "lib/Kconfig.kgdb"



source "lib/Kconfig.ubsan"



config ARCH_HAS_DEVMEM_IS_ALLOWED

	bool
@@ -2154,8 +2171,12 @@ config IO_STRICT_DEVMEM 


	  If in doubt, say Y.



menu "$(SRCARCH) Debugging"



source "arch/$(SRCARCH)/Kconfig.debug"



endmenu



config HYPERV_TESTING

	bool "Microsoft Hyper-V driver testing"

	default n

lib/Kconfig

+1 −1

File changed.

Contains only whitespace changes.

lib/Kconfig.kgdb

+4 −4

File changed.

Contains only whitespace changes.

CRA Git | Maintained and supported by SUSTech CRA and CCSE