Skip to content
Snippets Groups Projects
Select Git revision
  • 8e18faeac3e4d4b3ff3d705cd46d0fcb710b09d0
  • vme-testing default
  • ci-test
  • master
  • remoteproc
  • am625-sk-ov5640
  • pcal6534-upstreaming
  • lps22df-upstreaming
  • msc-upstreaming
  • imx8mp
  • iio/noa1305
  • vme-next
  • vme-next-4.14-rc4
  • v4.14-rc4
  • v4.14-rc3
  • v4.14-rc2
  • v4.14-rc1
  • v4.13
  • vme-next-4.13-rc7
  • v4.13-rc7
  • v4.13-rc6
  • v4.13-rc5
  • v4.13-rc4
  • v4.13-rc3
  • v4.13-rc2
  • v4.13-rc1
  • v4.12
  • v4.12-rc7
  • v4.12-rc6
  • v4.12-rc5
  • v4.12-rc4
  • v4.12-rc3
32 results

Kconfig.debug

Blame
  • Kconfig.debug 70.04 KiB
    menu "Kernel hacking"
    
    menu "printk and dmesg options"
    
    config PRINTK_TIME
    	bool "Show timing information on printks"
    	depends on PRINTK
    	help
    	  Selecting this option causes time stamps of the printk()
    	  messages to be added to the output of the syslog() system
    	  call and at the console.
    
    	  The timestamp is always recorded internally, and exported
    	  to /dev/kmsg. This flag just specifies if the timestamp should
    	  be included, not that the timestamp is recorded.
    
    	  The behavior is also controlled by the kernel command line
    	  parameter printk.time=1. See Documentation/admin-guide/kernel-parameters.rst
    
    config PRINTK_CALLER
    	bool "Show caller information on printks"
    	depends on PRINTK
    	help
    	  Selecting this option causes printk() to add a caller "thread id" (if
    	  in task context) or a caller "processor id" (if not in task context)
    	  to every message.
    
    	  This option is intended for environments where multiple threads
    	  concurrently call printk() for many times, for it is difficult to
    	  interpret without knowing where these lines (or sometimes individual
    	  line which was divided into multiple lines due to race) came from.
    
    	  Since toggling after boot makes the code racy, currently there is
    	  no option to enable/disable at the kernel command line parameter or
    	  sysfs interface.
    
    config CONSOLE_LOGLEVEL_DEFAULT
    	int "Default console loglevel (1-15)"
    	range 1 15
    	default "7"
    	help
    	  Default loglevel to determine what will be printed on the console.
    
    	  Setting a default here is equivalent to passing in loglevel=<x> in
    	  the kernel bootargs. loglevel=<x> continues to override whatever
    	  value is specified here as well.
    
    	  Note: This does not affect the log level of un-prefixed printk()
    	  usage in the kernel. That is controlled by the MESSAGE_LOGLEVEL_DEFAULT
    	  option.
    
    config CONSOLE_LOGLEVEL_QUIET
    	int "quiet console loglevel (1-15)"
    	range 1 15
    	default "4"
    	help
    	  loglevel to use when "quiet" is passed on the kernel commandline.
    
    	  When "quiet" is passed on the kernel commandline this loglevel
    	  will be used as the loglevel. IOW passing "quiet" will be the
    	  equivalent of passing "loglevel=<CONSOLE_LOGLEVEL_QUIET>"
    
    config MESSAGE_LOGLEVEL_DEFAULT
    	int "Default message log level (1-7)"
    	range 1 7
    	default "4"
    	help
    	  Default log level for printk statements with no specified priority.
    
    	  This was hard-coded to KERN_WARNING since at least 2.6.10 but folks
    	  that are auditing their logs closely may want to set it to a lower
    	  priority.
    
    	  Note: This does not affect what message level gets printed on the console
    	  by default. To change that, use loglevel=<x> in the kernel bootargs,
    	  or pick a different CONSOLE_LOGLEVEL_DEFAULT configuration value.
    
    config BOOT_PRINTK_DELAY
    	bool "Delay each boot printk message by N milliseconds"
    	depends on DEBUG_KERNEL && PRINTK && GENERIC_CALIBRATE_DELAY
    	help
    	  This build option allows you to read kernel boot messages
    	  by inserting a short delay after each one.  The delay is
    	  specified in milliseconds on the kernel command line,
    	  using "boot_delay=N".
    
    	  It is likely that you would also need to use "lpj=M" to preset
    	  the "loops per jiffie" value.
    	  See a previous boot log for the "lpj" value to use for your
    	  system, and then set "lpj=M" before setting "boot_delay=N".
    	  NOTE:  Using this option may adversely affect SMP systems.
    	  I.e., processors other than the first one may not boot up.
    	  BOOT_PRINTK_DELAY also may cause LOCKUP_DETECTOR to detect
    	  what it believes to be lockup conditions.
    
    config DYNAMIC_DEBUG
    	bool "Enable dynamic printk() support"
    	default n
    	depends on PRINTK
    	depends on DEBUG_FS
    	help
    
    	  Compiles debug level messages into the kernel, which would not
    	  otherwise be available at runtime. These messages can then be
    	  enabled/disabled based on various levels of scope - per source file,
    	  function, module, format string, and line number. This mechanism
    	  implicitly compiles in all pr_debug() and dev_dbg() calls, which
    	  enlarges the kernel text size by about 2%.
    
    	  If a source file is compiled with DEBUG flag set, any
    	  pr_debug() calls in it are enabled by default, but can be
    	  disabled at runtime as below.  Note that DEBUG flag is
    	  turned on by many CONFIG_*DEBUG* options.
    
    	  Usage:
    
    	  Dynamic debugging is controlled via the 'dynamic_debug/control' file,
    	  which is contained in the 'debugfs' filesystem. Thus, the debugfs
    	  filesystem must first be mounted before making use of this feature.
    	  We refer the control file as: <debugfs>/dynamic_debug/control. This
    	  file contains a list of the debug statements that can be enabled. The
    	  format for each line of the file is:
    
    		filename:lineno [module]function flags format
    
    	  filename : source file of the debug statement
    	  lineno : line number of the debug statement
    	  module : module that contains the debug statement
    	  function : function that contains the debug statement
              flags : '=p' means the line is turned 'on' for printing
              format : the format used for the debug statement
    
    	  From a live system:
    
    		nullarbor:~ # cat <debugfs>/dynamic_debug/control
    		# filename:lineno [module]function flags format
    		fs/aio.c:222 [aio]__put_ioctx =_ "__put_ioctx:\040freeing\040%p\012"
    		fs/aio.c:248 [aio]ioctx_alloc =_ "ENOMEM:\040nr_events\040too\040high\012"
    		fs/aio.c:1770 [aio]sys_io_cancel =_ "calling\040cancel\012"
    
    	  Example usage:
    
    		// enable the message at line 1603 of file svcsock.c
    		nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >
    						<debugfs>/dynamic_debug/control
    
    		// enable all the messages in file svcsock.c
    		nullarbor:~ # echo -n 'file svcsock.c +p' >
    						<debugfs>/dynamic_debug/control
    
    		// enable all the messages in the NFS server module
    		nullarbor:~ # echo -n 'module nfsd +p' >
    						<debugfs>/dynamic_debug/control
    
    		// enable all 12 messages in the function svc_process()
    		nullarbor:~ # echo -n 'func svc_process +p' >
    						<debugfs>/dynamic_debug/control
    
    		// disable all 12 messages in the function svc_process()
    		nullarbor:~ # echo -n 'func svc_process -p' >
    						<debugfs>/dynamic_debug/control
    
    	  See Documentation/admin-guide/dynamic-debug-howto.rst for additional
    	  information.
    
    endmenu # "printk and dmesg options"
    
    menu "Compile-time checks and compiler options"
    
    config DEBUG_INFO
    	bool "Compile the kernel with debug info"
    	depends on DEBUG_KERNEL && !COMPILE_TEST
    	help
              If you say Y here the resulting kernel image will include
    	  debugging info resulting in a larger kernel image.
    	  This adds debug symbols to the kernel and modules (gcc -g), and
    	  is needed if you intend to use kernel crashdump or binary object
    	  tools like crash, kgdb, LKCD, gdb, etc on the kernel.
    	  Say Y here only if you plan to debug the kernel.
    
    	  If unsure, say N.
    
    config DEBUG_INFO_REDUCED
    	bool "Reduce debugging information"
    	depends on DEBUG_INFO
    	help
    	  If you say Y here gcc is instructed to generate less debugging
    	  information for structure types. This means that tools that
    	  need full debugging information (like kgdb or systemtap) won't
    	  be happy. But if you merely need debugging information to
    	  resolve line numbers there is no loss. Advantage is that
    	  build directory object sizes shrink dramatically over a full
    	  DEBUG_INFO build and compile times are reduced too.
    	  Only works with newer gcc versions.
    
    config DEBUG_INFO_SPLIT
    	bool "Produce split debuginfo in .dwo files"
    	depends on DEBUG_INFO
    	depends on $(cc-option,-gsplit-dwarf)
    	help
    	  Generate debug info into separate .dwo files. This significantly
    	  reduces the build directory size for builds with DEBUG_INFO,
    	  because it stores the information only once on disk in .dwo
    	  files instead of multiple times in object files and executables.
    	  In addition the debug information is also compressed.
    
    	  Requires recent gcc (4.7+) and recent gdb/binutils.
    	  Any tool that packages or reads debug information would need
    	  to know about the .dwo files and include them.
    	  Incompatible with older versions of ccache.
    
    config DEBUG_INFO_DWARF4
    	bool "Generate dwarf4 debuginfo"
    	depends on DEBUG_INFO
    	depends on $(cc-option,-gdwarf-4)
    	help
    	  Generate dwarf4 debug info. This requires recent versions
    	  of gcc and gdb. It makes the debug information larger.
    	  But it significantly improves the success of resolving
    	  variables in gdb on optimized code.
    
    config DEBUG_INFO_BTF
    	bool "Generate BTF typeinfo"
    	depends on DEBUG_INFO
    	help
    	  Generate deduplicated BTF type information from DWARF debug info.
    	  Turning this on expects presence of pahole tool, which will convert
    	  DWARF type info into equivalent deduplicated BTF type info.
    
    config GDB_SCRIPTS
    	bool "Provide GDB scripts for kernel debugging"
    	depends on DEBUG_INFO
    	help
    	  This creates the required links to GDB helper scripts in the
    	  build directory. If you load vmlinux into gdb, the helper
    	  scripts will be automatically imported by gdb as well, and
    	  additional functions are available to analyze a Linux kernel
    	  instance. See Documentation/dev-tools/gdb-kernel-debugging.rst
    	  for further details.
    
    config ENABLE_MUST_CHECK
    	bool "Enable __must_check logic"
    	default y
    	help
    	  Enable the __must_check logic in the kernel build.  Disable this to
    	  suppress the "warning: ignoring return value of 'foo', declared with
    	  attribute warn_unused_result" messages.
    
    config FRAME_WARN
    	int "Warn for stack frames larger than (needs gcc 4.4)"
    	range 0 8192
    	default 2048 if GCC_PLUGIN_LATENT_ENTROPY
    	default 1280 if (!64BIT && PARISC)
    	default 1024 if (!64BIT && !PARISC)
    	default 2048 if 64BIT
    	help
    	  Tell gcc to warn at build time for stack frames larger than this.
    	  Setting this too low will cause a lot of warnings.
    	  Setting it to 0 disables the warning.
    	  Requires gcc 4.4
    
    config STRIP_ASM_SYMS
    	bool "Strip assembler-generated symbols during link"
    	default n
    	help
    	  Strip internal assembler-generated symbols during a link (symbols
    	  that look like '.Lxxx') so they don't pollute the output of
    	  get_wchan() and suchlike.
    
    config READABLE_ASM
            bool "Generate readable assembler code"
            depends on DEBUG_KERNEL
            help
              Disable some compiler optimizations that tend to generate human unreadable
              assembler output. This may make the kernel slightly slower, but it helps
              to keep kernel developers who have to stare a lot at assembler listings
              sane.
    
    config UNUSED_SYMBOLS
    	bool "Enable unused/obsolete exported symbols"
    	default y if X86
    	help
    	  Unused but exported symbols make the kernel needlessly bigger.  For
    	  that reason most of these unused exports will soon be removed.  This
    	  option is provided temporarily to provide a transition period in case
    	  some external kernel module needs one of these symbols anyway. If you
    	  encounter such a case in your module, consider if you are actually
    	  using the right API.  (rationale: since nobody in the kernel is using
    	  this in a module, there is a pretty good chance it's actually the
    	  wrong interface to use).  If you really need the symbol, please send a
    	  mail to the linux kernel mailing list mentioning the symbol and why
    	  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_CHECK
    	bool "Run 'make headers_check' when building vmlinux"
    	depends on !UML
    	help
    	  This option will extract the user-visible kernel headers whenever
    	  building the kernel, and will run basic sanity checks on them to
    	  ensure that exported files do not attempt to include files which
    	  were not exported, etc.
    
    	  If you're making modifications to header files which are
    	  relevant for userspace, say 'Y', and check the headers
    	  exported to $(INSTALL_HDR_PATH) (usually 'usr/include' in
    	  your build tree), to make sure they're suitable.
    
    config OPTIMIZE_INLINING
    	bool "Allow compiler to uninline functions marked 'inline'"
    	help
    	  This option determines if the kernel forces gcc to inline the functions
    	  developers have marked 'inline'. Doing so takes away freedom from gcc to
    	  do what it thinks is best, which is desirable for the gcc 3.x series of
    	  compilers. The gcc 4.x series have a rewritten inlining algorithm and
    	  enabling this option will generate a smaller kernel there. Hopefully
    	  this algorithm is so good that allowing gcc 4.x and above to make the
    	  decision will become the default in the future. Until then this option
    	  is there to test gcc for this.
    
    	  If unsure, say N.
    
    config DEBUG_SECTION_MISMATCH
    	bool "Enable full Section mismatch analysis"
    	help
    	  The section mismatch analysis checks if there are illegal
    	  references from one section to another section.
    	  During linktime or runtime, some sections are dropped;
    	  any use of code/data previously in these sections would
    	  most likely result in an oops.
    	  In the code, functions and variables are annotated with
    	  __init,, etc. (see the full list in include/linux/init.h),
    	  which results in the code/data being placed in specific sections.
    	  The section mismatch analysis is always performed after a full
    	  kernel build, and enabling this option causes the following
    	  additional steps to occur:
    	  - Add the option -fno-inline-functions-called-once to gcc commands.
    	    When inlining a function annotated with __init in a non-init
    	    function, we would lose the section information and thus
    	    the analysis would not catch the illegal reference.
    	    This option tells gcc to inline less (but it does result in
    	    a larger kernel).
    	  - Run the section mismatch analysis for each module/built-in.a file.
    	    When we run the section mismatch analysis on vmlinux.o, we
    	    lose valuable information about where the mismatch was
    	    introduced.
    	    Running the analysis for each module/built-in.a file
    	    tells where the mismatch happens much closer to the
    	    source. The drawback is that the same mismatch is
    	    reported at least twice.
    	  - Enable verbose reporting from modpost in order to help resolve
    	    the section mismatches that are reported.
    
    config SECTION_MISMATCH_WARN_ONLY
    	bool "Make section mismatch errors non-fatal"
    	default y
    	help
    	  If you say N here, the build process will fail if there are any
    	  section mismatch, instead of just throwing warnings.
    
    	  If unsure, say Y.
    
    #
    # Select this config option from the architecture Kconfig, if it
    # is preferred to always offer frame pointers as a config
    # option on the architecture (regardless of KERNEL_DEBUG):
    #
    config ARCH_WANT_FRAME_POINTERS
    	bool
    
    config FRAME_POINTER
    	bool "Compile the kernel with frame pointers"
    	depends on DEBUG_KERNEL && (M68K || UML || SUPERH) || ARCH_WANT_FRAME_POINTERS
    	default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS
    	help
    	  If you say Y here the resulting kernel image will be slightly
    	  larger and slower, but it gives very useful debugging information
    	  in case of kernel bugs. (precise oopses/stacktraces/warnings)
    
    config STACK_VALIDATION
    	bool "Compile-time stack metadata validation"
    	depends on HAVE_STACK_VALIDATION
    	default n
    	help
    	  Add compile-time checks to validate stack metadata, including frame
    	  pointers (if CONFIG_FRAME_POINTER is enabled).  This helps ensure
    	  that runtime stack traces are more reliable.
    
    	  This is also a prerequisite for generation of ORC unwind data, which
    	  is needed for CONFIG_UNWINDER_ORC.
    
    	  For more information, see
    	  tools/objtool/Documentation/stack-validation.txt.
    
    config DEBUG_FORCE_WEAK_PER_CPU
    	bool "Force weak per-cpu definitions"
    	depends on DEBUG_KERNEL
    	help
    	  s390 and alpha require percpu variables in modules to be
    	  defined weak to work around addressing range issue which
    	  puts the following two restrictions on percpu variable
    	  definitions.
    
    	  1. percpu symbols must be unique whether static or not
    	  2. percpu variables can't be defined inside a function
    
    	  To ensure that generic code follows the above rules, this
    	  option forces all percpu variables to be defined as weak.
    
    endmenu # "Compiler options"
    
    config MAGIC_SYSRQ
    	bool "Magic SysRq key"
    	depends on !UML
    	help
    	  If you say Y here, you will have some control over the system even
    	  if the system crashes for example during kernel debugging (e.g., you
    	  will be able to flush the buffer cache to disk, reboot the system
    	  immediately or dump some status information). This is accomplished
    	  by pressing various keys while holding SysRq (Alt+PrintScreen). It
    	  also works on a serial console (on PC hardware at least), if you
    	  send a BREAK and then within 5 seconds a command keypress. The
    	  keys are documented in <file:Documentation/admin-guide/sysrq.rst>.
    	  Don't say Y unless you really know what this hack does.
    
    config MAGIC_SYSRQ_DEFAULT_ENABLE
    	hex "Enable magic SysRq key functions by default"
    	depends on MAGIC_SYSRQ
    	default 0x1
    	help
    	  Specifies which SysRq key functions are enabled by default.
    	  This may be set to 1 or 0 to enable or disable them all, or
    	  to a bitmask as described in Documentation/admin-guide/sysrq.rst.
    
    config MAGIC_SYSRQ_SERIAL
    	bool "Enable magic SysRq key over serial"
    	depends on MAGIC_SYSRQ
    	default y
    	help
    	  Many embedded boards have a disconnected TTL level serial which can
    	  generate some garbage that can lead to spurious false sysrq detects.
    	  This option allows you to decide whether you want to enable the
    	  magic SysRq key.
    
    config DEBUG_KERNEL
    	bool "Kernel debugging"
    	help
    	  Say Y here if you are developing drivers or trying to debug and
    	  identify kernel problems.
    
    menu "Memory Debugging"
    
    source "mm/Kconfig.debug"
    
    config DEBUG_OBJECTS
    	bool "Debug object operations"
    	depends on DEBUG_KERNEL
    	help
    	  If you say Y here, additional code will be inserted into the
    	  kernel to track the life time of various objects and validate
    	  the operations on those objects.
    
    config DEBUG_OBJECTS_SELFTEST
    	bool "Debug objects selftest"
    	depends on DEBUG_OBJECTS
    	help
    	  This enables the selftest of the object debug code.
    
    config DEBUG_OBJECTS_FREE
    	bool "Debug objects in freed memory"
    	depends on DEBUG_OBJECTS
    	help
    	  This enables checks whether a k/v free operation frees an area
    	  which contains an object which has not been deactivated
    	  properly. This can make kmalloc/kfree-intensive workloads
    	  much slower.
    
    config DEBUG_OBJECTS_TIMERS
    	bool "Debug timer objects"
    	depends on DEBUG_OBJECTS
    	help
    	  If you say Y here, additional code will be inserted into the
    	  timer routines to track the life time of timer objects and
    	  validate the timer operations.
    
    config DEBUG_OBJECTS_WORK
    	bool "Debug work objects"
    	depends on DEBUG_OBJECTS
    	help
    	  If you say Y here, additional code will be inserted into the
    	  work queue routines to track the life time of work objects and
    	  validate the work operations.
    
    config DEBUG_OBJECTS_RCU_HEAD
    	bool "Debug RCU callbacks objects"
    	depends on DEBUG_OBJECTS
    	help
    	  Enable this to turn on debugging of RCU list heads (call_rcu() usage).
    
    config DEBUG_OBJECTS_PERCPU_COUNTER
    	bool "Debug percpu counter objects"
    	depends on DEBUG_OBJECTS
    	help
    	  If you say Y here, additional code will be inserted into the
    	  percpu counter routines to track the life time of percpu counter
    	  objects and validate the percpu counter operations.
    
    config DEBUG_OBJECTS_ENABLE_DEFAULT
    	int "debug_objects bootup default value (0-1)"
            range 0 1
            default "1"
            depends on DEBUG_OBJECTS
            help
              Debug objects boot parameter default value
    
    config DEBUG_SLAB
    	bool "Debug slab memory allocations"
    	depends on DEBUG_KERNEL && SLAB
    	help
    	  Say Y here to have the kernel do limited verification on memory
    	  allocation as well as poisoning memory on free to catch use of freed
    	  memory. This can make kmalloc/kfree-intensive workloads much slower.
    
    config DEBUG_SLAB_LEAK
    	bool "Memory leak debugging"
    	depends on DEBUG_SLAB
    
    config SLUB_DEBUG_ON
    	bool "SLUB debugging on by default"
    	depends on SLUB && SLUB_DEBUG
    	default n
    	help
    	  Boot with debugging on by default. SLUB boots by default with
    	  the runtime debug capabilities switched off. Enabling this is
    	  equivalent to specifying the "slub_debug" parameter on boot.
    	  There is no support for more fine grained debug control like
    	  possible with slub_debug=xxx. SLUB debugging may be switched
    	  off in a kernel built with CONFIG_SLUB_DEBUG_ON by specifying
    	  "slub_debug=-".
    
    config SLUB_STATS
    	default n
    	bool "Enable SLUB performance statistics"
    	depends on SLUB && SYSFS
    	help
    	  SLUB statistics are useful to debug SLUBs allocation behavior in
    	  order find ways to optimize the allocator. This should never be
    	  enabled for production use since keeping statistics slows down
    	  the allocator by a few percentage points. The slabinfo command
    	  supports the determination of the most active slabs to figure
    	  out which slabs are relevant to a particular load.
    	  Try running: slabinfo -DA
    
    config HAVE_DEBUG_KMEMLEAK
    	bool
    
    config DEBUG_KMEMLEAK
    	bool "Kernel memory leak detector"
    	depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK
    	select DEBUG_FS
    	select STACKTRACE if STACKTRACE_SUPPORT
    	select KALLSYMS
    	select CRC32
    	help
    	  Say Y here if you want to enable the memory leak
    	  detector. The memory allocation/freeing is traced in a way
    	  similar to the Boehm's conservative garbage collector, the
    	  difference being that the orphan objects are not freed but
    	  only shown in /sys/kernel/debug/kmemleak. Enabling this
    	  feature will introduce an overhead to memory
    	  allocations. See Documentation/dev-tools/kmemleak.rst for more
    	  details.
    
    	  Enabling DEBUG_SLAB or SLUB_DEBUG may increase the chances
    	  of finding leaks due to the slab objects poisoning.
    
    	  In order to access the kmemleak file, debugfs needs to be
    	  mounted (usually at /sys/kernel/debug).
    
    config DEBUG_KMEMLEAK_EARLY_LOG_SIZE
    	int "Maximum kmemleak early log entries"
    	depends on DEBUG_KMEMLEAK
    	range 200 40000
    	default 400
    	help
    	  Kmemleak must track all the memory allocations to avoid
    	  reporting false positives. Since memory may be allocated or
    	  freed before kmemleak is initialised, an early log buffer is
    	  used to store these actions. If kmemleak reports "early log
    	  buffer exceeded", please increase this value.
    
    config DEBUG_KMEMLEAK_TEST
    	tristate "Simple test for the kernel memory leak detector"
    	depends on DEBUG_KMEMLEAK && m
    	help
    	  This option enables a module that explicitly leaks memory.
    
    	  If unsure, say N.
    
    config DEBUG_KMEMLEAK_DEFAULT_OFF
    	bool "Default kmemleak to off"
    	depends on DEBUG_KMEMLEAK
    	help
    	  Say Y here to disable kmemleak by default. It can then be enabled
    	  on the command line via kmemleak=on.
    
    config DEBUG_KMEMLEAK_AUTO_SCAN
    	bool "Enable kmemleak auto scan thread on boot up"
    	default y
    	depends on DEBUG_KMEMLEAK
    	help
    	  Depending on the cpu, kmemleak scan may be cpu intensive and can
    	  stall user tasks at times. This option enables/disables automatic
    	  kmemleak scan at boot up.
    
    	  Say N here to disable kmemleak auto scan thread to stop automatic
    	  scanning. Disabling this option disables automatic reporting of
    	  memory leaks.
    
    	  If unsure, say Y.
    
    config DEBUG_STACK_USAGE
    	bool "Stack utilization instrumentation"
    	depends on DEBUG_KERNEL && !IA64
    	help
    	  Enables the display of the minimum amount of free stack which each
    	  task has ever had available in the sysrq-T and sysrq-P debug output.
    
    	  This option will slow down process creation somewhat.
    
    config DEBUG_VM
    	bool "Debug VM"
    	depends on DEBUG_KERNEL
    	help
    	  Enable this to turn on extended checks in the virtual-memory system
              that may impact performance.
    
    	  If unsure, say N.
    
    config DEBUG_VM_VMACACHE
    	bool "Debug VMA caching"
    	depends on DEBUG_VM
    	help
    	  Enable this to turn on VMA caching debug information. Doing so
    	  can cause significant overhead, so only enable it in non-production
    	  environments.
    
    	  If unsure, say N.
    
    config DEBUG_VM_RB
    	bool "Debug VM red-black trees"
    	depends on DEBUG_VM
    	help
    	  Enable VM red-black tree debugging information and extra validations.
    
    	  If unsure, say N.
    
    config DEBUG_VM_PGFLAGS
    	bool "Debug page-flags operations"
    	depends on DEBUG_VM
    	help
    	  Enables extra validation on page flags operations.
    
    	  If unsure, say N.
    
    config ARCH_HAS_DEBUG_VIRTUAL
    	bool
    
    config DEBUG_VIRTUAL
    	bool "Debug VM translations"
    	depends on DEBUG_KERNEL && ARCH_HAS_DEBUG_VIRTUAL
    	help
    	  Enable some costly sanity checks in virtual to page code. This can
    	  catch mistakes with virt_to_page() and friends.
    
    	  If unsure, say N.
    
    config DEBUG_NOMMU_REGIONS
    	bool "Debug the global anon/private NOMMU mapping region tree"
    	depends on DEBUG_KERNEL && !MMU
    	help
    	  This option causes the global tree of anonymous and private mapping
    	  regions to be regularly checked for invalid topology.
    
    config DEBUG_MEMORY_INIT
    	bool "Debug memory initialisation" if EXPERT
    	default !EXPERT
    	help
    	  Enable this for additional checks during memory initialisation.
    	  The sanity checks verify aspects of the VM such as the memory model
    	  and other information provided by the architecture. Verbose
    	  information will be printed at KERN_DEBUG loglevel depending
    	  on the mminit_loglevel= command-line option.
    
    	  If unsure, say Y
    
    config MEMORY_NOTIFIER_ERROR_INJECT
    	tristate "Memory hotplug notifier error injection module"
    	depends on MEMORY_HOTPLUG_SPARSE && NOTIFIER_ERROR_INJECTION
    	help
    	  This option provides the ability to inject artificial errors to
    	  memory hotplug notifier chain callbacks.  It is controlled through
    	  debugfs interface under /sys/kernel/debug/notifier-error-inject/memory
    
    	  If the notifier call chain should be failed with some events
    	  notified, write the error code to "actions/<notifier event>/error".
    
    	  Example: Inject memory hotplug offline error (-12 == -ENOMEM)
    
    	  # cd /sys/kernel/debug/notifier-error-inject/memory
    	  # echo -12 > actions/MEM_GOING_OFFLINE/error
    	  # echo offline > /sys/devices/system/memory/memoryXXX/state
    	  bash: echo: write error: Cannot allocate memory
    
    	  To compile this code as a module, choose M here: the module will
    	  be called memory-notifier-error-inject.
    
    	  If unsure, say N.
    
    config DEBUG_PER_CPU_MAPS
    	bool "Debug access to per_cpu maps"
    	depends on DEBUG_KERNEL
    	depends on SMP
    	help
    	  Say Y to verify that the per_cpu map being accessed has
    	  been set up. This adds a fair amount of code to kernel memory
    	  and decreases performance.
    
    	  Say N if unsure.
    
    config DEBUG_HIGHMEM
    	bool "Highmem debugging"
    	depends on DEBUG_KERNEL && HIGHMEM
    	help
    	  This option enables additional error checking for high memory
    	  systems.  Disable for production systems.
    
    config HAVE_DEBUG_STACKOVERFLOW
    	bool
    
    config DEBUG_STACKOVERFLOW
    	bool "Check for stack overflows"
    	depends on DEBUG_KERNEL && HAVE_DEBUG_STACKOVERFLOW
    	---help---
    	  Say Y here if you want to check for overflows of kernel, IRQ
    	  and exception stacks (if your architecture uses them). This
    	  option will show detailed messages if free stack space drops
    	  below a certain limit.
    
    	  These kinds of bugs usually occur when call-chains in the
    	  kernel get too deep, especially when interrupts are
    	  involved.
    
    	  Use this in cases where you see apparently random memory
    	  corruption, especially if it appears in 'struct thread_info'
    
    	  If in doubt, say "N".
    
    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
    	help
    	  Enable this to generate a spurious interrupt as soon as a shared
    	  interrupt handler is registered, and just before one is deregistered.
    	  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"
    
    config LOCKUP_DETECTOR
    	bool
    
    config SOFTLOCKUP_DETECTOR
    	bool "Detect Soft Lockups"
    	depends on DEBUG_KERNEL && !S390
    	select LOCKUP_DETECTOR
    	help
    	  Say Y here to enable the kernel to act as a watchdog to detect
    	  soft lockups.
    
    	  Softlockups are bugs that cause the kernel to loop in kernel
    	  mode for more than 20 seconds, without giving other tasks a
    	  chance to run.  The current stack trace is displayed upon
    	  detection and the system will stay locked up.
    
    config BOOTPARAM_SOFTLOCKUP_PANIC
    	bool "Panic (Reboot) On Soft Lockups"
    	depends on SOFTLOCKUP_DETECTOR
    	help
    	  Say Y here to enable the kernel to panic on "soft lockups",
    	  which are bugs that cause the kernel to loop in kernel
    	  mode for more than 20 seconds (configurable using the watchdog_thresh
    	  sysctl), without giving other tasks a chance to run.
    
    	  The panic can be used in combination with panic_timeout,
    	  to cause the system to reboot automatically after a
    	  lockup has been detected. This feature is useful for
    	  high-availability systems that have uptime guarantees and
    	  where a lockup must be resolved ASAP.
    
    	  Say N if unsure.
    
    config BOOTPARAM_SOFTLOCKUP_PANIC_VALUE
    	int
    	depends on SOFTLOCKUP_DETECTOR
    	range 0 1
    	default 0 if !BOOTPARAM_SOFTLOCKUP_PANIC
    	default 1 if BOOTPARAM_SOFTLOCKUP_PANIC
    
    config HARDLOCKUP_DETECTOR_PERF
    	bool
    	select SOFTLOCKUP_DETECTOR
    
    #
    # Enables a timestamp based low pass filter to compensate for perf based
    # hard lockup detection which runs too fast due to turbo modes.
    #
    config HARDLOCKUP_CHECK_TIMESTAMP
    	bool
    
    #
    # arch/ can define HAVE_HARDLOCKUP_DETECTOR_ARCH to provide their own hard
    # lockup detector rather than the perf based detector.
    #
    config HARDLOCKUP_DETECTOR
    	bool "Detect Hard Lockups"
    	depends on DEBUG_KERNEL && !S390
    	depends on HAVE_HARDLOCKUP_DETECTOR_PERF || HAVE_HARDLOCKUP_DETECTOR_ARCH
    	select LOCKUP_DETECTOR
    	select HARDLOCKUP_DETECTOR_PERF if HAVE_HARDLOCKUP_DETECTOR_PERF
    	select HARDLOCKUP_DETECTOR_ARCH if HAVE_HARDLOCKUP_DETECTOR_ARCH
    	help
    	  Say Y here to enable the kernel to act as a watchdog to detect
    	  hard lockups.
    
    	  Hardlockups are bugs that cause the CPU to loop in kernel mode
    	  for more than 10 seconds, without letting other interrupts have a
    	  chance to run.  The current stack trace is displayed upon detection
    	  and the system will stay locked up.
    
    config BOOTPARAM_HARDLOCKUP_PANIC
    	bool "Panic (Reboot) On Hard Lockups"
    	depends on HARDLOCKUP_DETECTOR
    	help
    	  Say Y here to enable the kernel to panic on "hard lockups",
    	  which are bugs that cause the kernel to loop in kernel
    	  mode with interrupts disabled for more than 10 seconds (configurable
    	  using the watchdog_thresh sysctl).
    
    	  Say N if unsure.
    
    config BOOTPARAM_HARDLOCKUP_PANIC_VALUE
    	int
    	depends on HARDLOCKUP_DETECTOR
    	range 0 1
    	default 0 if !BOOTPARAM_HARDLOCKUP_PANIC
    	default 1 if BOOTPARAM_HARDLOCKUP_PANIC
    
    config DETECT_HUNG_TASK
    	bool "Detect Hung Tasks"
    	depends on DEBUG_KERNEL
    	default SOFTLOCKUP_DETECTOR
    	help
    	  Say Y here to enable the kernel to detect "hung tasks",
    	  which are bugs that cause the task to be stuck in
    	  uninterruptible "D" state indefinitely.
    
    	  When a hung task is detected, the kernel will print the
    	  current stack trace (which you should report), but the
    	  task will stay in uninterruptible state. If lockdep is
    	  enabled then all held locks will also be reported. This
    	  feature has negligible overhead.
    
    config DEFAULT_HUNG_TASK_TIMEOUT
    	int "Default timeout for hung task detection (in seconds)"
    	depends on DETECT_HUNG_TASK
    	default 120
    	help
    	  This option controls the default timeout (in seconds) used
    	  to determine when a task has become non-responsive and should
    	  be considered hung.
    
    	  It can be adjusted at runtime via the kernel.hung_task_timeout_secs
    	  sysctl or by writing a value to
    	  /proc/sys/kernel/hung_task_timeout_secs.
    
    	  A timeout of 0 disables the check.  The default is two minutes.
    	  Keeping the default should be fine in most cases.
    
    config BOOTPARAM_HUNG_TASK_PANIC
    	bool "Panic (Reboot) On Hung Tasks"
    	depends on DETECT_HUNG_TASK
    	help
    	  Say Y here to enable the kernel to panic on "hung tasks",
    	  which are bugs that cause the kernel to leave a task stuck
    	  in uninterruptible "D" state.
    
    	  The panic can be used in combination with panic_timeout,
    	  to cause the system to reboot automatically after a
    	  hung task has been detected. This feature is useful for
    	  high-availability systems that have uptime guarantees and
    	  where a hung tasks must be resolved ASAP.
    
    	  Say N if unsure.
    
    config BOOTPARAM_HUNG_TASK_PANIC_VALUE
    	int
    	depends on DETECT_HUNG_TASK
    	range 0 1
    	default 0 if !BOOTPARAM_HUNG_TASK_PANIC
    	default 1 if BOOTPARAM_HUNG_TASK_PANIC
    
    config WQ_WATCHDOG
    	bool "Detect Workqueue Stalls"
    	depends on DEBUG_KERNEL
    	help
    	  Say Y here to enable stall detection on workqueues.  If a
    	  worker pool doesn't make forward progress on a pending work
    	  item for over a given amount of time, 30s by default, a
    	  warning message is printed along with dump of workqueue
    	  state.  This can be configured through kernel parameter
    	  "workqueue.watchdog_thresh" and its sysfs counterpart.
    
    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
    	default y
    	help
    	  If you say Y here, the /proc/sched_debug file will be provided
    	  that can help debug the scheduler. The runtime overhead of this
    	  option is minimal.
    
    config SCHED_INFO
    	bool
    	default n
    
    config SCHEDSTATS
    	bool "Collect scheduler statistics"
    	depends on DEBUG_KERNEL && PROC_FS
    	select SCHED_INFO
    	help
    	  If you say Y here, additional code will be inserted into the
    	  scheduler and related routines to collect statistics about
    	  scheduler behavior and provide them in /proc/schedstat.  These
    	  stats may be useful for both tuning and debugging the scheduler
    	  If you aren't debugging the scheduler or trying to tune a specific
    	  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
    	  This option will enable additional timekeeping sanity checks
    	  which may be helpful when diagnosing issues where timekeeping
    	  problems are suspected.
    
    	  This may include checks in the timekeeping hotpaths, so this
    	  option may have a (very small) performance impact to some
    	  workloads.
    
    	  If unsure, say N.
    
    config DEBUG_PREEMPT
    	bool "Debug preemptible kernel"
    	depends on DEBUG_KERNEL && PREEMPT && TRACE_IRQFLAGS_SUPPORT
    	default y
    	help
    	  If you say Y here then the kernel will use a debug variant of the
    	  commonly used smp_processor_id() function and will print warnings
    	  if kernel code uses it in a preemption-unsafe way. Also, the kernel
    	  will detect preemption count underflows.
    
    menu "Lock Debugging (spinlocks, mutexes, etc...)"
    
    config LOCK_DEBUGGING_SUPPORT
    	bool
    	depends on TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
    	default y
    
    config PROVE_LOCKING
    	bool "Lock debugging: prove locking correctness"
    	depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
    	select LOCKDEP
    	select DEBUG_SPINLOCK
    	select DEBUG_MUTEXES
    	select DEBUG_RT_MUTEXES if RT_MUTEXES
    	select DEBUG_RWSEMS if RWSEM_SPIN_ON_OWNER
    	select DEBUG_WW_MUTEX_SLOWPATH
    	select DEBUG_LOCK_ALLOC
    	select TRACE_IRQFLAGS
    	default n
    	help
    	 This feature enables the kernel to prove that all locking
    	 that occurs in the kernel runtime is mathematically
    	 correct: that under no circumstance could an arbitrary (and
    	 not yet triggered) combination of observed locking
    	 sequences (on an arbitrary number of CPUs, running an
    	 arbitrary number of tasks and interrupt contexts) cause a
    	 deadlock.
    
    	 In short, this feature enables the kernel to report locking
    	 related deadlocks before they actually occur.
    
    	 The proof does not depend on how hard and complex a
    	 deadlock scenario would be to trigger: how many
    	 participant CPUs, tasks and irq-contexts would be needed
    	 for it to trigger. The proof also does not depend on
    	 timing: if a race and a resulting deadlock is possible
    	 theoretically (no matter how unlikely the race scenario
    	 is), it will be proven so and will immediately be
    	 reported by the kernel (once the event is observed that
    	 makes the deadlock theoretically possible).
    
    	 If a deadlock is impossible (i.e. the locking rules, as
    	 observed by the kernel, are mathematically correct), the
    	 kernel reports nothing.
    
    	 NOTE: this feature can also be enabled for rwlocks, mutexes
    	 and rwsems - in which case all dependencies between these
    	 different locking variants are observed and mapped too, and
    	 the proof of observed correctness is also maintained for an
    	 arbitrary combination of these separate locking variants.
    
    	 For more details, see Documentation/locking/lockdep-design.txt.
    
    config LOCK_STAT
    	bool "Lock usage statistics"
    	depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
    	select LOCKDEP
    	select DEBUG_SPINLOCK
    	select DEBUG_MUTEXES
    	select DEBUG_RT_MUTEXES if RT_MUTEXES
    	select DEBUG_LOCK_ALLOC
    	default n
    	help
    	 This feature enables tracking lock contention points
    
    	 For more details, see Documentation/locking/lockstat.txt
    
    	 This also enables lock events required by "perf lock",
    	 subcommand of perf.
    	 If you want to use "perf lock", you also need to turn on
    	 CONFIG_EVENT_TRACING.
    
    	 CONFIG_LOCK_STAT defines "contended" and "acquired" lock events.
    	 (CONFIG_LOCKDEP defines "acquire" and "release" events.)
    
    config DEBUG_RT_MUTEXES
    	bool "RT Mutex debugging, deadlock detection"
    	depends on DEBUG_KERNEL && RT_MUTEXES
    	help
    	 This allows rt mutex semantics violations and rt mutex related
    	 deadlocks (lockups) to be detected and reported automatically.
    
    config DEBUG_SPINLOCK
    	bool "Spinlock and rw-lock debugging: basic checks"
    	depends on DEBUG_KERNEL
    	select UNINLINE_SPIN_UNLOCK
    	help
    	  Say Y here and build SMP to catch missing spinlock initialization
    	  and certain other kinds of spinlock errors commonly made.  This is
    	  best used in conjunction with the NMI watchdog so that spinlock
    	  deadlocks are also debuggable.
    
    config DEBUG_MUTEXES
    	bool "Mutex debugging: basic checks"
    	depends on DEBUG_KERNEL
    	help
    	 This feature allows mutex semantics violations to be detected and
    	 reported.
    
    config DEBUG_WW_MUTEX_SLOWPATH
    	bool "Wait/wound mutex debugging: Slowpath testing"
    	depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
    	select DEBUG_LOCK_ALLOC
    	select DEBUG_SPINLOCK
    	select DEBUG_MUTEXES
    	help
    	 This feature enables slowpath testing for w/w mutex users by
    	 injecting additional -EDEADLK wound/backoff cases. Together with
    	 the full mutex checks enabled with (CONFIG_PROVE_LOCKING) this
    	 will test all possible w/w mutex interface abuse with the
    	 exception of simply not acquiring all the required locks.
    	 Note that this feature can introduce significant overhead, so
    	 it really should not be enabled in a production or distro kernel,
    	 even a debug kernel.  If you are a driver writer, enable it.  If
    	 you are a distro, do not.
    
    config DEBUG_RWSEMS
    	bool "RW Semaphore debugging: basic checks"
    	depends on DEBUG_KERNEL && RWSEM_SPIN_ON_OWNER
    	help
    	  This debugging feature allows mismatched rw semaphore locks and unlocks
    	  to be detected and reported.
    
    config DEBUG_LOCK_ALLOC
    	bool "Lock debugging: detect incorrect freeing of live locks"
    	depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
    	select DEBUG_SPINLOCK
    	select DEBUG_MUTEXES
    	select DEBUG_RT_MUTEXES if RT_MUTEXES
    	select LOCKDEP
    	help
    	 This feature will check whether any held lock (spinlock, rwlock,
    	 mutex or rwsem) is incorrectly freed by the kernel, via any of the
    	 memory-freeing routines (kfree(), kmem_cache_free(), free_pages(),
    	 vfree(), etc.), whether a live lock is incorrectly reinitialized via
    	 spin_lock_init()/mutex_init()/etc., or whether there is any lock
    	 held during task exit.
    
    config LOCKDEP
    	bool
    	depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
    	select STACKTRACE
    	select FRAME_POINTER if !MIPS && !PPC && !ARM && !S390 && !MICROBLAZE && !ARC && !X86
    	select KALLSYMS
    	select KALLSYMS_ALL
    
    config LOCKDEP_SMALL
    	bool
    
    config DEBUG_LOCKDEP
    	bool "Lock dependency engine debugging"
    	depends on DEBUG_KERNEL && LOCKDEP
    	help
    	  If you say Y here, the lock dependency engine will do
    	  additional runtime checks to debug itself, at the price
    	  of more runtime overhead.
    
    config DEBUG_ATOMIC_SLEEP
    	bool "Sleep inside atomic section checking"
    	select PREEMPT_COUNT
    	depends on DEBUG_KERNEL
    	depends on !ARCH_NO_PREEMPT
    	help
    	  If you say Y here, various routines which may sleep will become very
    	  noisy if they are called inside atomic sections: when a spinlock is
    	  held, inside an rcu read side critical section, inside preempt disabled
    	  sections, inside an interrupt, etc...
    
    config DEBUG_LOCKING_API_SELFTESTS
    	bool "Locking API boot-time self-tests"
    	depends on DEBUG_KERNEL
    	help
    	  Say Y here if you want the kernel to run a short self-test during
    	  bootup. The self-test checks whether common types of locking bugs
    	  are detected by debugging mechanisms or not. (if you disable
    	  lock debugging then those bugs wont be detected of course.)
    	  The following locking APIs are covered: spinlocks, rwlocks,
    	  mutexes and rwsems.
    
    config LOCK_TORTURE_TEST
    	tristate "torture tests for locking"
    	depends on DEBUG_KERNEL
    	select TORTURE_TEST
    	help
    	  This option provides a kernel module that runs torture tests
    	  on kernel locking primitives.  The kernel module may be built
    	  after the fact on the running kernel to be tested, if desired.
    
    	  Say Y here if you want kernel locking-primitive torture tests
    	  to be built into the kernel.
    	  Say M if you want these torture tests to build as a module.
    	  Say N if you are unsure.
    
    config WW_MUTEX_SELFTEST
    	tristate "Wait/wound mutex selftests"
    	help
    	  This option provides a kernel module that runs tests on the
    	  on the struct ww_mutex locking API.
    
    	  It is recommended to enable DEBUG_WW_MUTEX_SLOWPATH in conjunction
    	  with this test harness.
    
    	  Say M if you want these self tests to build as a module.
    	  Say N if you are unsure.
    
    endmenu # lock debugging
    
    config TRACE_IRQFLAGS
    	bool
    	help
    	  Enables hooks to interrupt enabling and disabling for
    	  either tracing or lock debugging.
    
    config STACKTRACE
    	bool "Stack backtrace support"
    	depends on STACKTRACE_SUPPORT
    	help
    	  This option causes the kernel to create a /proc/pid/stack for
    	  every process, showing its current stack trace.
    	  It is also used by various kernel debugging features that require
    	  stack trace generation.
    
    config WARN_ALL_UNSEEDED_RANDOM
    	bool "Warn for all uses of unseeded randomness"
    	default n
    	help
    	  Some parts of the kernel contain bugs relating to their use of
    	  cryptographically secure random numbers before it's actually possible
    	  to generate those numbers securely. This setting ensures that these
    	  flaws don't go unnoticed, by enabling a message, should this ever
    	  occur. This will allow people with obscure setups to know when things
    	  are going wrong, so that they might contact developers about fixing
    	  it.
    
    	  Unfortunately, on some models of some architectures getting
    	  a fully seeded CRNG is extremely difficult, and so this can
    	  result in dmesg getting spammed for a surprisingly long
    	  time.  This is really bad from a security perspective, and
    	  so architecture maintainers really need to do what they can
    	  to get the CRNG seeded sooner after the system is booted.
    	  However, since users cannot do anything actionable to
    	  address this, by default the kernel will issue only a single
    	  warning for the first use of unseeded randomness.
    
    	  Say Y here if you want to receive warnings for all uses of
    	  unseeded randomness.  This will be of use primarily for
    	  those developers interested in improving the security of
    	  Linux kernels running on their architecture (or
    	  subarchitecture).
    
    config DEBUG_KOBJECT
    	bool "kobject debugging"
    	depends on DEBUG_KERNEL
    	help
    	  If you say Y here, some extra kobject debugging messages will be sent
    	  to the syslog.
    
    config DEBUG_KOBJECT_RELEASE
    	bool "kobject release debugging"
    	depends on DEBUG_OBJECTS_TIMERS
    	help
    	  kobjects are reference counted objects.  This means that their
    	  last reference count put is not predictable, and the kobject can
    	  live on past the point at which a driver decides to drop it's
    	  initial reference to the kobject gained on allocation.  An
    	  example of this would be a struct device which has just been
    	  unregistered.
    
    	  However, some buggy drivers assume that after such an operation,
    	  the memory backing the kobject can be immediately freed.  This
    	  goes completely against the principles of a refcounted object.
    
    	  If you say Y here, the kernel will delay the release of kobjects
    	  on the last reference count to improve the visibility of this
    	  kind of kobject release bug.
    
    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.
    
    config DEBUG_LIST
    	bool "Debug linked list manipulation"
    	depends on DEBUG_KERNEL || BUG_ON_DATA_CORRUPTION
    	help
    	  Enable this to turn on extended checks in the linked-list
    	  walking routines.
    
    	  If unsure, say N.
    
    config DEBUG_PLIST
    	bool "Debug priority linked list manipulation"
    	depends on DEBUG_KERNEL
    	help
    	  Enable this to turn on extended checks in the priority-ordered
    	  linked-list (plist) walking routines.  This checks the entire
    	  list multiple times during each manipulation.
    
    	  If unsure, say N.
    
    config DEBUG_SG
    	bool "Debug SG table operations"
    	depends on DEBUG_KERNEL
    	help
    	  Enable this to turn on checks on scatter-gather tables. This can
    	  help find problems with drivers that do not properly initialize
    	  their sg tables.
    
    	  If unsure, say N.
    
    config DEBUG_NOTIFIERS
    	bool "Debug notifier call chains"
    	depends on DEBUG_KERNEL
    	help
    	  Enable this to turn on sanity checking for notifier call chains.
    	  This is most useful for kernel developers to make sure that
    	  modules properly unregister themselves from notifier chains.
    	  This is a relatively cheap check but if you care about maximum
    	  performance, say N.
    
    config DEBUG_CREDENTIALS
    	bool "Debug credential management"
    	depends on DEBUG_KERNEL
    	help
    	  Enable this to turn on some debug checking for credential
    	  management.  The additional code keeps track of the number of
    	  pointers from task_structs to any given cred struct, and checks to
    	  see that this number never exceeds the usage count of the cred
    	  struct.
    
    	  Furthermore, if SELinux is enabled, this also checks that the
    	  security pointer in the cred struct is never seen to be invalid.
    
    	  If unsure, say N.
    
    source "kernel/rcu/Kconfig.debug"
    
    config DEBUG_WQ_FORCE_RR_CPU
    	bool "Force round-robin CPU selection for unbound work items"
    	depends on DEBUG_KERNEL
    	default n
    	help
    	  Workqueue used to implicitly guarantee that work items queued
    	  without explicit CPU specified are put on the local CPU.  This
    	  guarantee is no longer true and while local CPU is still
    	  preferred work items may be put on foreign CPUs.  Kernel
    	  parameter "workqueue.debug_force_rr_cpu" is added to force
    	  round-robin CPU selection to flush out usages which depend on the
    	  now broken guarantee.  This config option enables the debug
    	  feature by default.  When enabled, memory and cache locality will
    	  be impacted.
    
    config DEBUG_BLOCK_EXT_DEVT
            bool "Force extended block device numbers and spread them"
    	depends on DEBUG_KERNEL
    	depends on BLOCK
    	default n
    	help
    	  BIG FAT WARNING: ENABLING THIS OPTION MIGHT BREAK BOOTING ON
    	  SOME DISTRIBUTIONS.  DO NOT ENABLE THIS UNLESS YOU KNOW WHAT
    	  YOU ARE DOING.  Distros, please enable this and fix whatever
    	  is broken.
    
    	  Conventionally, block device numbers are allocated from
    	  predetermined contiguous area.  However, extended block area
    	  may introduce non-contiguous block device numbers.  This
    	  option forces most block device numbers to be allocated from
    	  the extended space and spreads them to discover kernel or
    	  userland code paths which assume predetermined contiguous
    	  device number allocation.
    
    	  Note that turning on this debug option shuffles all the
    	  device numbers for all IDE and SCSI devices including libata
    	  ones, so root partition specified using device number
    	  directly (via rdev or root=MAJ:MIN) won't work anymore.
    	  Textual device names (root=/dev/sdXn) will continue to work.
    
    	  Say N if you are unsure.
    
    config CPU_HOTPLUG_STATE_CONTROL
    	bool "Enable CPU hotplug state control"
    	depends on DEBUG_KERNEL
    	depends on HOTPLUG_CPU
    	default n
    	help
    	  Allows to write steps between "offline" and "online" to the CPUs
    	  sysfs target file so states can be stepped granular. This is a debug
    	  option for now as the hotplug machinery cannot be stopped and
    	  restarted at arbitrary points yet.
    
    	  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
    	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.
    
    menuconfig RUNTIME_TESTING_MENU
    	bool "Runtime Testing"
    	def_bool y
    
    if RUNTIME_TESTING_MENU
    
    config LKDTM
    	tristate "Linux Kernel Dump Test Tool Module"
    	depends on DEBUG_FS
    	help
    	This module enables testing of the different dumping mechanisms by
    	inducing system failures at predefined crash points.
    	If you don't need it: say N
    	Choose M here to compile this code as a module. The module will be
    	called lkdtm.
    
    	Documentation on how to use the module can be found in
    	Documentation/fault-injection/provoke-crashes.txt
    
    config TEST_LIST_SORT
    	tristate "Linked list sorting test"
    	depends on DEBUG_KERNEL || m
    	help
    	  Enable this to turn on 'list_sort()' function test. This test is
    	  executed only once during system boot (so affects only boot time),
    	  or at module load time.
    
    	  If unsure, say N.
    
    config TEST_SORT
    	tristate "Array-based sort test"
    	depends on DEBUG_KERNEL || m
    	help
    	  This option enables the self-test function of 'sort()' at boot,
    	  or at module load time.
    
    	  If unsure, say N.
    
    config KPROBES_SANITY_TEST
    	bool "Kprobes sanity tests"
    	depends on DEBUG_KERNEL
    	depends on KPROBES
    	help
    	  This option provides for testing basic kprobes functionality on
    	  boot. Samples of kprobe and kretprobe are inserted and
    	  verified for functionality.
    
    	  Say N if you are unsure.
    
    config BACKTRACE_SELF_TEST
    	tristate "Self test for the backtrace code"
    	depends on DEBUG_KERNEL
    	help
    	  This option provides a kernel module that can be used to test
    	  the kernel stack backtrace code. This option is not useful
    	  for distributions or general kernels, but only for kernel
    	  developers working on architecture code.
    
    	  Note that if you want to also test saved backtraces, you will
    	  have to enable STACKTRACE as well.
    
    	  Say N if you are unsure.
    
    config RBTREE_TEST
    	tristate "Red-Black tree test"
    	depends on DEBUG_KERNEL
    	help
    	  A benchmark measuring the performance of the rbtree library.
    	  Also includes rbtree invariant checks.
    
    config INTERVAL_TREE_TEST
    	tristate "Interval tree test"
    	depends on DEBUG_KERNEL
    	select INTERVAL_TREE
    	help
    	  A benchmark measuring the performance of the interval tree library
    
    config PERCPU_TEST
    	tristate "Per cpu operations test"
    	depends on m && DEBUG_KERNEL
    	help
    	  Enable this option to build test module which validates per-cpu
    	  operations.
    
    	  If unsure, say N.
    
    config ATOMIC64_SELFTEST
    	tristate "Perform an atomic64_t self-test"
    	help
    	  Enable this option to test the atomic64_t functions at boot or
    	  at module load time.
    
    	  If unsure, say N.
    
    config ASYNC_RAID6_TEST
    	tristate "Self test for hardware accelerated raid6 recovery"
    	depends on ASYNC_RAID6_RECOV
    	select ASYNC_MEMCPY
    	---help---
    	  This is a one-shot self test that permutes through the
    	  recovery of all the possible two disk failure scenarios for a
    	  N-disk array.  Recovery is performed with the asynchronous
    	  raid6 recovery routines, and will optionally use an offload
    	  engine if one is available.
    
    	  If unsure, say N.
    
    config TEST_HEXDUMP
    	tristate "Test functions located in the hexdump module at runtime"
    
    config TEST_STRING_HELPERS
    	tristate "Test functions located in the string_helpers module at runtime"
    
    config TEST_STRSCPY
    	tristate "Test strscpy*() family of functions at runtime"
    
    config TEST_KSTRTOX
    	tristate "Test kstrto*() family of functions at runtime"
    
    config TEST_PRINTF
    	tristate "Test printf() family of functions at runtime"
    
    config TEST_BITMAP
    	tristate "Test bitmap_*() family of functions at runtime"
    	help
    	  Enable this option to test the bitmap functions at boot.
    
    	  If unsure, say N.
    
    config TEST_BITFIELD
    	tristate "Test bitfield functions at runtime"
    	help
    	  Enable this option to test the bitfield functions at boot.
    
    	  If unsure, say N.
    
    config TEST_UUID
    	tristate "Test functions located in the uuid module at runtime"
    
    config TEST_XARRAY
    	tristate "Test the XArray code at runtime"
    
    config TEST_OVERFLOW
    	tristate "Test check_*_overflow() functions at runtime"
    
    config TEST_RHASHTABLE
    	tristate "Perform selftest on resizable hash table"
    	help
    	  Enable this option to test the rhashtable functions at boot.
    
    	  If unsure, say N.
    
    config TEST_HASH
    	tristate "Perform selftest on hash functions"
    	help
    	  Enable this option to test the kernel's integer (<linux/hash.h>),
    	  string (<linux/stringhash.h>), and siphash (<linux/siphash.h>)
    	  hash functions on boot (or module load).
    
    	  This is intended to help people writing architecture-specific
    	  optimized versions.  If unsure, say N.
    
    config TEST_IDA
    	tristate "Perform selftest on IDA functions"
    
    config TEST_PARMAN
    	tristate "Perform selftest on priority array manager"
    	depends on PARMAN
    	help
    	  Enable this option to test priority array manager on boot
    	  (or module load).
    
    	  If unsure, say N.
    
    config TEST_LKM
    	tristate "Test module loading with 'hello world' module"
    	depends on m
    	help
    	  This builds the "test_module" module that emits "Hello, world"
    	  on printk when loaded. It is designed to be used for basic
    	  evaluation of the module loading subsystem (for example when
    	  validating module verification). It lacks any extra dependencies,
    	  and will not normally be loaded by the system unless explicitly
    	  requested by name.
    
    	  If unsure, say N.
    
    config TEST_VMALLOC
    	tristate "Test module for stress/performance analysis of vmalloc allocator"
    	default n
           depends on MMU
    	depends on m
    	help
    	  This builds the "test_vmalloc" module that should be used for
    	  stress and performance analysis. So, any new change for vmalloc
    	  subsystem can be evaluated from performance and stability point
    	  of view.
    
    	  If unsure, say N.
    
    config TEST_USER_COPY
    	tristate "Test user/kernel boundary protections"
    	depends on m
    	help
    	  This builds the "test_user_copy" module that runs sanity checks
    	  on the copy_to/from_user infrastructure, making sure basic
    	  user/kernel boundary testing is working. If it fails to load,
    	  a regression has been detected in the user/kernel memory boundary
    	  protections.
    
    	  If unsure, say N.
    
    config TEST_BPF
    	tristate "Test BPF filter functionality"
    	depends on m && NET
    	help
    	  This builds the "test_bpf" module that runs various test vectors
    	  against the BPF interpreter or BPF JIT compiler depending on the
    	  current setting. This is in particular useful for BPF JIT compiler
    	  development, but also to run regression tests against changes in
    	  the interpreter code. It also enables test stubs for eBPF maps and
    	  verifier used by user space verifier testsuite.
    
    	  If unsure, say N.
    
    config FIND_BIT_BENCHMARK
    	tristate "Test find_bit functions"
    	help
    	  This builds the "test_find_bit" module that measure find_*_bit()
    	  functions performance.
    
    	  If unsure, say N.
    
    config TEST_FIRMWARE
    	tristate "Test firmware loading via userspace interface"
    	depends on FW_LOADER
    	help
    	  This builds the "test_firmware" module that creates a userspace
    	  interface for testing firmware loading. This can be used to
    	  control the triggering of firmware loading without needing an
    	  actual firmware-using device. The contents can be rechecked by
    	  userspace.
    
    	  If unsure, say N.
    
    config TEST_SYSCTL
    	tristate "sysctl test driver"
    	depends on PROC_SYSCTL
    	help
    	  This builds the "test_sysctl" module. This driver enables to test the
    	  proc sysctl interfaces available to drivers safely without affecting
    	  production knobs which might alter system functionality.
    
    	  If unsure, say N.
    
    config TEST_UDELAY
    	tristate "udelay test driver"
    	help
    	  This builds the "udelay_test" module that helps to make sure
    	  that udelay() is working properly.
    
    	  If unsure, say N.
    
    config TEST_STATIC_KEYS
    	tristate "Test static keys"
    	depends on m
    	help
    	  Test the static key interfaces.
    
    	  If unsure, say N.
    
    config TEST_KMOD
    	tristate "kmod stress tester"
    	depends on m
    	depends on NETDEVICES && NET_CORE && INET # for TUN
    	depends on BLOCK
    	select TEST_LKM
    	select XFS_FS
    	select TUN
    	select BTRFS_FS
    	help
    	  Test the kernel's module loading mechanism: kmod. kmod implements
    	  support to load modules using the Linux kernel's usermode helper.
    	  This test provides a series of tests against kmod.
    
    	  Although technically you can either build test_kmod as a module or
    	  into the kernel we disallow building it into the kernel since
    	  it stress tests request_module() and this will very likely cause
    	  some issues by taking over precious threads available from other
    	  module load requests, ultimately this could be fatal.
    
    	  To run tests run:
    
    	  tools/testing/selftests/kmod/kmod.sh --help
    
    	  If unsure, say N.
    
    config TEST_DEBUG_VIRTUAL
    	tristate "Test CONFIG_DEBUG_VIRTUAL feature"
    	depends on DEBUG_VIRTUAL
    	help
    	  Test the kernel's ability to detect incorrect calls to
    	  virt_to_phys() done against the non-linear part of the
    	  kernel's virtual address map.
    
    	  If unsure, say N.
    
    config TEST_MEMCAT_P
    	tristate "Test memcat_p() helper function"
    	help
    	  Test the memcat_p() helper for correctly merging two
    	  pointer arrays together.
    
    	  If unsure, say N.
    
    config TEST_LIVEPATCH
    	tristate "Test livepatching"
    	default n
    	depends on DYNAMIC_DEBUG
    	depends on LIVEPATCH
    	depends on m
    	help
    	  Test kernel livepatching features for correctness.  The tests will
    	  load test modules that will be livepatched in various scenarios.
    
    	  To run all the livepatching tests:
    
    	  make -C tools/testing/selftests TARGETS=livepatch run_tests
    
    	  Alternatively, individual tests may be invoked:
    
    	  tools/testing/selftests/livepatch/test-callbacks.sh
    	  tools/testing/selftests/livepatch/test-livepatch.sh
    	  tools/testing/selftests/livepatch/test-shadow-vars.sh
    
    	  If unsure, say N.
    
    config TEST_OBJAGG
    	tristate "Perform selftest on object aggreration manager"
    	default n
    	depends on OBJAGG
    	help
    	  Enable this option to test object aggregation manager on boot
    	  (or module load).
    
    
    config TEST_STACKINIT
    	tristate "Test level of stack variable initialization"
    	help
    	  Test if the kernel is zero-initializing stack variables and
    	  padding. Coverage is controlled by compiler flags,
    	  CONFIG_GCC_PLUGIN_STRUCTLEAK, CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF,
    	  or CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL.
    
    	  If unsure, say N.
    
    endif # RUNTIME_TESTING_MENU
    
    config MEMTEST
    	bool "Memtest"
    	---help---
    	  This option adds a kernel parameter 'memtest', which allows memtest
    	  to be set.
    	        memtest=0, mean disabled; -- default
    	        memtest=1, mean do 1 test pattern;
    	        ...
    	        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
    
    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.
    
    source "arch/$(SRCARCH)/Kconfig.debug"
    
    endmenu # Kernel hacking