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

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
...@@ -173,6 +173,15 @@ config SYMBOLIC_ERRNAME ...@@ -173,6 +173,15 @@ config SYMBOLIC_ERRNAME
of the number 28. It makes the kernel image slightly larger of the number 28. It makes the kernel image slightly larger
(about 3KB), but can make the kernel logs easier to read. (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" endmenu # "printk and dmesg options"
menu "Compile-time checks and compiler options" menu "Compile-time checks and compiler options"
...@@ -286,18 +295,6 @@ config READABLE_ASM ...@@ -286,18 +295,6 @@ config READABLE_ASM
to keep kernel developers who have to stare a lot at assembler listings to keep kernel developers who have to stare a lot at assembler listings
sane. 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 config HEADERS_INSTALL
bool "Install uapi headers to usr/include" bool "Install uapi headers to usr/include"
depends on !UML depends on !UML
...@@ -399,6 +396,8 @@ config DEBUG_FORCE_WEAK_PER_CPU ...@@ -399,6 +396,8 @@ config DEBUG_FORCE_WEAK_PER_CPU
endmenu # "Compiler options" endmenu # "Compiler options"
menu "Generic Kernel Debugging Instruments"
config MAGIC_SYSRQ config MAGIC_SYSRQ
bool "Magic SysRq key" bool "Magic SysRq key"
depends on !UML depends on !UML
...@@ -432,6 +431,24 @@ config MAGIC_SYSRQ_SERIAL ...@@ -432,6 +431,24 @@ config MAGIC_SYSRQ_SERIAL
This option allows you to decide whether you want to enable the This option allows you to decide whether you want to enable the
magic SysRq key. 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 config DEBUG_KERNEL
bool "Kernel debugging" bool "Kernel debugging"
help help
...@@ -624,6 +641,18 @@ config DEBUG_STACK_USAGE ...@@ -624,6 +641,18 @@ config DEBUG_STACK_USAGE
This option will slow down process creation somewhat. 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 config DEBUG_VM
bool "Debug VM" bool "Debug VM"
depends on DEBUG_KERNEL depends on DEBUG_KERNEL
...@@ -756,53 +785,6 @@ source "lib/Kconfig.kasan" ...@@ -756,53 +785,6 @@ source "lib/Kconfig.kasan"
endmenu # "Memory Debugging" 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 config DEBUG_SHIRQ
bool "Debug shared IRQ handlers" bool "Debug shared IRQ handlers"
depends on DEBUG_KERNEL depends on DEBUG_KERNEL
...@@ -812,7 +794,35 @@ config DEBUG_SHIRQ ...@@ -812,7 +794,35 @@ config DEBUG_SHIRQ
Drivers ought to be able to handle interrupts coming in at those Drivers ought to be able to handle interrupts coming in at those
points; some don't and need to be caught. 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 config LOCKUP_DETECTOR
bool bool
...@@ -970,33 +980,7 @@ config WQ_WATCHDOG ...@@ -970,33 +980,7 @@ config WQ_WATCHDOG
endmenu # "Debug lockups and hangs" endmenu # "Debug lockups and hangs"
config PANIC_ON_OOPS menu "Scheduler Debugging"
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 config SCHED_DEBUG
bool "Collect scheduler debugging info" bool "Collect scheduler debugging info"
...@@ -1024,17 +1008,7 @@ config SCHEDSTATS ...@@ -1024,17 +1008,7 @@ config SCHEDSTATS
application, you can say N to avoid the very slight overhead application, you can say N to avoid the very slight overhead
this adds. this adds.
config SCHED_STACK_END_CHECK endmenu
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 config DEBUG_TIMEKEEPING
bool "Enable extra timekeeping sanity checking" bool "Enable extra timekeeping sanity checking"
...@@ -1338,14 +1312,7 @@ config DEBUG_KOBJECT_RELEASE ...@@ -1338,14 +1312,7 @@ config DEBUG_KOBJECT_RELEASE
config HAVE_DEBUG_BUGVERBOSE config HAVE_DEBUG_BUGVERBOSE
bool bool
config DEBUG_BUGVERBOSE menu "Debug kernel data structures"
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.
config DEBUG_LIST config DEBUG_LIST
bool "Debug linked list manipulation" bool "Debug linked list manipulation"
...@@ -1386,6 +1353,18 @@ config DEBUG_NOTIFIERS ...@@ -1386,6 +1353,18 @@ config DEBUG_NOTIFIERS
This is a relatively cheap check but if you care about maximum This is a relatively cheap check but if you care about maximum
performance, say N. 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 config DEBUG_CREDENTIALS
bool "Debug credential management" bool "Debug credential management"
depends on DEBUG_KERNEL depends on DEBUG_KERNEL
...@@ -1458,6 +1437,54 @@ config CPU_HOTPLUG_STATE_CONTROL ...@@ -1458,6 +1437,54 @@ config CPU_HOTPLUG_STATE_CONTROL
Say N if your are unsure. 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 config NOTIFIER_ERROR_INJECTION
tristate "Notifier error injection" tristate "Notifier error injection"
depends on DEBUG_KERNEL depends on DEBUG_KERNEL
...@@ -1616,53 +1643,57 @@ config FAULT_INJECTION_STACKTRACE_FILTER ...@@ -1616,53 +1643,57 @@ config FAULT_INJECTION_STACKTRACE_FILTER
help help
Provide stacktrace filter for fault-injection capabilities Provide stacktrace filter for fault-injection capabilities
config LATENCYTOP endmenu # "Kernel Testing and Coverage"
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" menu "Kernel Testing and Coverage"
config PROVIDE_OHCI1394_DMA_INIT config ARCH_HAS_KCOV
bool "Remote debugging over FireWire early on boot" bool
depends on PCI && X86
help help
If you want to debug problems which hang or crash the kernel early An architecture should select this when it can successfully
on boot and the crashing machine has a FireWire port, you can use build and run with CONFIG_KCOV. This typically requires
this feature to remotely access the memory of the crashed machine disabling instrumentation for some early boot code.
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 config CC_HAS_SANCOV_TRACE_PC
firescope and access all memory below 4GB using fireproxy from gdb. def_bool $(cc-option,-fsanitize-coverage=trace-pc)
Even controlling a kernel debugger is possible using remote DMA.
Usage:
If ohci1394_dma=early is used as boot parameter, it will initialize config KCOV
all OHCI1394 controllers which are found in the PCI config space. 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 If RANDOMIZE_BASE is enabled, PC values will not be stable across
devices cause a bus reset and thereby disable remote DMA for all different machines and across reboots. If you need stable PC values,
devices, be sure to have the cable plugged and FireWire enabled on disable RANDOMIZE_BASE.
the debugging host before booting the debug target for debugging.
This code (~1k) is freed after boot. By then, the firewire stack For more details, see Documentation/dev-tools/kcov.rst.
in charge of the OHCI-1394 controllers should be used instead.
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 menuconfig RUNTIME_TESTING_MENU
bool "Runtime Testing" bool "Runtime Testing"
...@@ -2099,22 +2130,8 @@ config MEMTEST ...@@ -2099,22 +2130,8 @@ config MEMTEST
memtest=17, mean do 17 test patterns. memtest=17, mean do 17 test patterns.
If you are unsure how to answer this question, answer N. 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 "samples/Kconfig"
source "lib/Kconfig.kgdb"
source "lib/Kconfig.ubsan"
config ARCH_HAS_DEVMEM_IS_ALLOWED config ARCH_HAS_DEVMEM_IS_ALLOWED
bool bool
...@@ -2154,8 +2171,12 @@ config IO_STRICT_DEVMEM ...@@ -2154,8 +2171,12 @@ config IO_STRICT_DEVMEM
If in doubt, say Y. If in doubt, say Y.
menu "$(SRCARCH) Debugging"
source "arch/$(SRCARCH)/Kconfig.debug" source "arch/$(SRCARCH)/Kconfig.debug"
endmenu
config HYPERV_TESTING config HYPERV_TESTING
bool "Microsoft Hyper-V driver testing" bool "Microsoft Hyper-V driver testing"
default n default n
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment