1menu "printk and dmesg options"
   2
   3config PRINTK_TIME
   4	bool "Show timing information on printks"
   5	depends on PRINTK
   6	help
   7	  Selecting this option causes time stamps of the printk()
   8	  messages to be added to the output of the syslog() system
   9	  call and at the console.
  10
  11	  The timestamp is always recorded internally, and exported
  12	  to /dev/kmsg. This flag just specifies if the timestamp should
  13	  be included, not that the timestamp is recorded.
  14
  15	  The behavior is also controlled by the kernel command line
  16	  parameter printk.time=1. See Documentation/admin-guide/kernel-parameters.rst
  17
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  18config CONSOLE_LOGLEVEL_DEFAULT
  19	int "Default console loglevel (1-15)"
  20	range 1 15
  21	default "7"
  22	help
  23	  Default loglevel to determine what will be printed on the console.
  24
  25	  Setting a default here is equivalent to passing in loglevel=<x> in
  26	  the kernel bootargs. loglevel=<x> continues to override whatever
  27	  value is specified here as well.
  28
  29	  Note: This does not affect the log level of un-prefixed printk()
  30	  usage in the kernel. That is controlled by the MESSAGE_LOGLEVEL_DEFAULT
  31	  option.
  32
 
 
 
 
 
 
 
 
 
 
 
  33config MESSAGE_LOGLEVEL_DEFAULT
  34	int "Default message log level (1-7)"
  35	range 1 7
  36	default "4"
  37	help
  38	  Default log level for printk statements with no specified priority.
  39
  40	  This was hard-coded to KERN_WARNING since at least 2.6.10 but folks
  41	  that are auditing their logs closely may want to set it to a lower
  42	  priority.
  43
  44	  Note: This does not affect what message level gets printed on the console
  45	  by default. To change that, use loglevel=<x> in the kernel bootargs,
  46	  or pick a different CONSOLE_LOGLEVEL_DEFAULT configuration value.
  47
  48config BOOT_PRINTK_DELAY
  49	bool "Delay each boot printk message by N milliseconds"
  50	depends on DEBUG_KERNEL && PRINTK && GENERIC_CALIBRATE_DELAY
  51	help
  52	  This build option allows you to read kernel boot messages
  53	  by inserting a short delay after each one.  The delay is
  54	  specified in milliseconds on the kernel command line,
  55	  using "boot_delay=N".
  56
  57	  It is likely that you would also need to use "lpj=M" to preset
  58	  the "loops per jiffie" value.
  59	  See a previous boot log for the "lpj" value to use for your
  60	  system, and then set "lpj=M" before setting "boot_delay=N".
  61	  NOTE:  Using this option may adversely affect SMP systems.
  62	  I.e., processors other than the first one may not boot up.
  63	  BOOT_PRINTK_DELAY also may cause LOCKUP_DETECTOR to detect
  64	  what it believes to be lockup conditions.
  65
  66config DYNAMIC_DEBUG
  67	bool "Enable dynamic printk() support"
  68	default n
  69	depends on PRINTK
  70	depends on DEBUG_FS
 
  71	help
  72
  73	  Compiles debug level messages into the kernel, which would not
  74	  otherwise be available at runtime. These messages can then be
  75	  enabled/disabled based on various levels of scope - per source file,
  76	  function, module, format string, and line number. This mechanism
  77	  implicitly compiles in all pr_debug() and dev_dbg() calls, which
  78	  enlarges the kernel text size by about 2%.
  79
  80	  If a source file is compiled with DEBUG flag set, any
  81	  pr_debug() calls in it are enabled by default, but can be
  82	  disabled at runtime as below.  Note that DEBUG flag is
  83	  turned on by many CONFIG_*DEBUG* options.
  84
  85	  Usage:
  86
  87	  Dynamic debugging is controlled via the 'dynamic_debug/control' file,
  88	  which is contained in the 'debugfs' filesystem. Thus, the debugfs
  89	  filesystem must first be mounted before making use of this feature.
 
  90	  We refer the control file as: <debugfs>/dynamic_debug/control. This
  91	  file contains a list of the debug statements that can be enabled. The
  92	  format for each line of the file is:
  93
  94		filename:lineno [module]function flags format
  95
  96	  filename : source file of the debug statement
  97	  lineno : line number of the debug statement
  98	  module : module that contains the debug statement
  99	  function : function that contains the debug statement
 100          flags : '=p' means the line is turned 'on' for printing
 101          format : the format used for the debug statement
 102
 103	  From a live system:
 104
 105		nullarbor:~ # cat <debugfs>/dynamic_debug/control
 106		# filename:lineno [module]function flags format
 107		fs/aio.c:222 [aio]__put_ioctx =_ "__put_ioctx:\040freeing\040%p\012"
 108		fs/aio.c:248 [aio]ioctx_alloc =_ "ENOMEM:\040nr_events\040too\040high\012"
 109		fs/aio.c:1770 [aio]sys_io_cancel =_ "calling\040cancel\012"
 110
 111	  Example usage:
 112
 113		// enable the message at line 1603 of file svcsock.c
 114		nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >
 115						<debugfs>/dynamic_debug/control
 116
 117		// enable all the messages in file svcsock.c
 118		nullarbor:~ # echo -n 'file svcsock.c +p' >
 119						<debugfs>/dynamic_debug/control
 120
 121		// enable all the messages in the NFS server module
 122		nullarbor:~ # echo -n 'module nfsd +p' >
 123						<debugfs>/dynamic_debug/control
 124
 125		// enable all 12 messages in the function svc_process()
 126		nullarbor:~ # echo -n 'func svc_process +p' >
 127						<debugfs>/dynamic_debug/control
 128
 129		// disable all 12 messages in the function svc_process()
 130		nullarbor:~ # echo -n 'func svc_process -p' >
 131						<debugfs>/dynamic_debug/control
 132
 133	  See Documentation/dynamic-debug-howto.txt for additional information.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 134
 135endmenu # "printk and dmesg options"
 136
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 137menu "Compile-time checks and compiler options"
 138
 139config DEBUG_INFO
 140	bool "Compile the kernel with debug info"
 141	depends on DEBUG_KERNEL && !COMPILE_TEST
 142	help
 143          If you say Y here the resulting kernel image will include
 144	  debugging info resulting in a larger kernel image.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 145	  This adds debug symbols to the kernel and modules (gcc -g), and
 146	  is needed if you intend to use kernel crashdump or binary object
 147	  tools like crash, kgdb, LKCD, gdb, etc on the kernel.
 148	  Say Y here only if you plan to debug the kernel.
 149
 150	  If unsure, say N.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 151
 152config DEBUG_INFO_REDUCED
 153	bool "Reduce debugging information"
 154	depends on DEBUG_INFO
 155	help
 156	  If you say Y here gcc is instructed to generate less debugging
 157	  information for structure types. This means that tools that
 158	  need full debugging information (like kgdb or systemtap) won't
 159	  be happy. But if you merely need debugging information to
 160	  resolve line numbers there is no loss. Advantage is that
 161	  build directory object sizes shrink dramatically over a full
 162	  DEBUG_INFO build and compile times are reduced too.
 163	  Only works with newer gcc versions.
 164
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 165config DEBUG_INFO_SPLIT
 166	bool "Produce split debuginfo in .dwo files"
 167	depends on DEBUG_INFO && !FRV
 
 
 
 
 
 168	help
 169	  Generate debug info into separate .dwo files. This significantly
 170	  reduces the build directory size for builds with DEBUG_INFO,
 171	  because it stores the information only once on disk in .dwo
 172	  files instead of multiple times in object files and executables.
 173	  In addition the debug information is also compressed.
 174
 175	  Requires recent gcc (4.7+) and recent gdb/binutils.
 176	  Any tool that packages or reads debug information would need
 177	  to know about the .dwo files and include them.
 178	  Incompatible with older versions of ccache.
 179
 180config DEBUG_INFO_DWARF4
 181	bool "Generate dwarf4 debuginfo"
 182	depends on DEBUG_INFO
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 183	help
 184	  Generate dwarf4 debug info. This requires recent versions
 185	  of gcc and gdb. It makes the debug information larger.
 186	  But it significantly improves the success of resolving
 187	  variables in gdb on optimized code.
 
 
 
 
 
 
 
 188
 189config GDB_SCRIPTS
 190	bool "Provide GDB scripts for kernel debugging"
 191	depends on DEBUG_INFO
 192	help
 193	  This creates the required links to GDB helper scripts in the
 194	  build directory. If you load vmlinux into gdb, the helper
 195	  scripts will be automatically imported by gdb as well, and
 196	  additional functions are available to analyze a Linux kernel
 197	  instance. See Documentation/dev-tools/gdb-kernel-debugging.rst
 198	  for further details.
 199
 200config ENABLE_WARN_DEPRECATED
 201	bool "Enable __deprecated logic"
 202	default y
 203	help
 204	  Enable the __deprecated logic in the kernel build.
 205	  Disable this to suppress the "warning: 'foo' is deprecated
 206	  (declared at kernel/power/somefile.c:1234)" messages.
 207
 208config ENABLE_MUST_CHECK
 209	bool "Enable __must_check logic"
 210	default y
 211	help
 212	  Enable the __must_check logic in the kernel build.  Disable this to
 213	  suppress the "warning: ignoring return value of 'foo', declared with
 214	  attribute warn_unused_result" messages.
 215
 216config FRAME_WARN
 217	int "Warn for stack frames larger than (needs gcc 4.4)"
 218	range 0 8192
 219	default 0 if KASAN
 220	default 2048 if GCC_PLUGIN_LATENT_ENTROPY
 
 
 
 221	default 1024 if !64BIT
 222	default 2048 if 64BIT
 223	help
 224	  Tell gcc to warn at build time for stack frames larger than this.
 225	  Setting this too low will cause a lot of warnings.
 226	  Setting it to 0 disables the warning.
 227	  Requires gcc 4.4
 228
 229config STRIP_ASM_SYMS
 230	bool "Strip assembler-generated symbols during link"
 231	default n
 232	help
 233	  Strip internal assembler-generated symbols during a link (symbols
 234	  that look like '.Lxxx') so they don't pollute the output of
 235	  get_wchan() and suchlike.
 236
 237config READABLE_ASM
 238        bool "Generate readable assembler code"
 239        depends on DEBUG_KERNEL
 240        help
 241          Disable some compiler optimizations that tend to generate human unreadable
 242          assembler output. This may make the kernel slightly slower, but it helps
 243          to keep kernel developers who have to stare a lot at assembler listings
 244          sane.
 245
 246config UNUSED_SYMBOLS
 247	bool "Enable unused/obsolete exported symbols"
 248	default y if X86
 249	help
 250	  Unused but exported symbols make the kernel needlessly bigger.  For
 251	  that reason most of these unused exports will soon be removed.  This
 252	  option is provided temporarily to provide a transition period in case
 253	  some external kernel module needs one of these symbols anyway. If you
 254	  encounter such a case in your module, consider if you are actually
 255	  using the right API.  (rationale: since nobody in the kernel is using
 256	  this in a module, there is a pretty good chance it's actually the
 257	  wrong interface to use).  If you really need the symbol, please send a
 258	  mail to the linux kernel mailing list mentioning the symbol and why
 259	  you really need it, and what the merge plan to the mainline kernel for
 260	  your module is.
 261
 262config PAGE_OWNER
 263	bool "Track page owner"
 264	depends on DEBUG_KERNEL && STACKTRACE_SUPPORT
 265	select DEBUG_FS
 266	select STACKTRACE
 267	select STACKDEPOT
 268	select PAGE_EXTENSION
 269	help
 270	  This keeps track of what call chain is the owner of a page, may
 271	  help to find bare alloc_page(s) leaks. Even if you include this
 272	  feature on your build, it is disabled in default. You should pass
 273	  "page_owner=on" to boot parameter in order to enable it. Eats
 274	  a fair amount of memory if enabled. See tools/vm/page_owner_sort.c
 275	  for user-space helper.
 276
 277	  If unsure, say N.
 278
 279config DEBUG_FS
 280	bool "Debug Filesystem"
 281	select SRCU
 282	help
 283	  debugfs is a virtual file system that kernel developers use to put
 284	  debugging files into.  Enable this option to be able to read and
 285	  write to these files.
 286
 287	  For detailed documentation on the debugfs API, see
 288	  Documentation/DocBook/filesystems.
 289
 290	  If unsure, say N.
 291
 292config HEADERS_CHECK
 293	bool "Run 'make headers_check' when building vmlinux"
 294	depends on !UML
 295	help
 296	  This option will extract the user-visible kernel headers whenever
 297	  building the kernel, and will run basic sanity checks on them to
 298	  ensure that exported files do not attempt to include files which
 299	  were not exported, etc.
 300
 301	  If you're making modifications to header files which are
 302	  relevant for userspace, say 'Y', and check the headers
 303	  exported to $(INSTALL_HDR_PATH) (usually 'usr/include' in
 304	  your build tree), to make sure they're suitable.
 305
 306config DEBUG_SECTION_MISMATCH
 307	bool "Enable full Section mismatch analysis"
 
 308	help
 309	  The section mismatch analysis checks if there are illegal
 310	  references from one section to another section.
 311	  During linktime or runtime, some sections are dropped;
 312	  any use of code/data previously in these sections would
 313	  most likely result in an oops.
 314	  In the code, functions and variables are annotated with
 315	  __init,, etc. (see the full list in include/linux/init.h),
 316	  which results in the code/data being placed in specific sections.
 317	  The section mismatch analysis is always performed after a full
 318	  kernel build, and enabling this option causes the following
 319	  additional steps to occur:
 320	  - Add the option -fno-inline-functions-called-once to gcc commands.
 321	    When inlining a function annotated with __init in a non-init
 322	    function, we would lose the section information and thus
 323	    the analysis would not catch the illegal reference.
 324	    This option tells gcc to inline less (but it does result in
 325	    a larger kernel).
 326	  - Run the section mismatch analysis for each module/built-in.o file.
 327	    When we run the section mismatch analysis on vmlinux.o, we
 328	    lose valuable information about where the mismatch was
 329	    introduced.
 330	    Running the analysis for each module/built-in.o file
 331	    tells where the mismatch happens much closer to the
 332	    source. The drawback is that the same mismatch is
 333	    reported at least twice.
 334	  - Enable verbose reporting from modpost in order to help resolve
 335	    the section mismatches that are reported.
 336
 337config SECTION_MISMATCH_WARN_ONLY
 338	bool "Make section mismatch errors non-fatal"
 339	default y
 340	help
 341	  If you say N here, the build process will fail if there are any
 342	  section mismatch, instead of just throwing warnings.
 343
 344	  If unsure, say Y.
 345
 
 
 
 
 
 
 
 
 
 
 
 
 
 346#
 347# Select this config option from the architecture Kconfig, if it
 348# is preferred to always offer frame pointers as a config
 349# option on the architecture (regardless of KERNEL_DEBUG):
 350#
 351config ARCH_WANT_FRAME_POINTERS
 352	bool
 353	help
 354
 355config FRAME_POINTER
 356	bool "Compile the kernel with frame pointers"
 357	depends on DEBUG_KERNEL && \
 358		(CRIS || M68K || FRV || UML || \
 359		 AVR32 || SUPERH || BLACKFIN || MN10300 || METAG) || \
 360		ARCH_WANT_FRAME_POINTERS
 361	default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS
 362	help
 363	  If you say Y here the resulting kernel image will be slightly
 364	  larger and slower, but it gives very useful debugging information
 365	  in case of kernel bugs. (precise oopses/stacktraces/warnings)
 366
 
 
 
 367config STACK_VALIDATION
 368	bool "Compile-time stack metadata validation"
 369	depends on HAVE_STACK_VALIDATION
 
 370	default n
 371	help
 372	  Add compile-time checks to validate stack metadata, including frame
 373	  pointers (if CONFIG_FRAME_POINTER is enabled).  This helps ensure
 374	  that runtime stack traces are more reliable.
 375
 376	  For more information, see
 377	  tools/objtool/Documentation/stack-validation.txt.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 378
 379config DEBUG_FORCE_WEAK_PER_CPU
 380	bool "Force weak per-cpu definitions"
 381	depends on DEBUG_KERNEL
 382	help
 383	  s390 and alpha require percpu variables in modules to be
 384	  defined weak to work around addressing range issue which
 385	  puts the following two restrictions on percpu variable
 386	  definitions.
 387
 388	  1. percpu symbols must be unique whether static or not
 389	  2. percpu variables can't be defined inside a function
 390
 391	  To ensure that generic code follows the above rules, this
 392	  option forces all percpu variables to be defined as weak.
 393
 394endmenu # "Compiler options"
 395
 
 
 396config MAGIC_SYSRQ
 397	bool "Magic SysRq key"
 398	depends on !UML
 399	help
 400	  If you say Y here, you will have some control over the system even
 401	  if the system crashes for example during kernel debugging (e.g., you
 402	  will be able to flush the buffer cache to disk, reboot the system
 403	  immediately or dump some status information). This is accomplished
 404	  by pressing various keys while holding SysRq (Alt+PrintScreen). It
 405	  also works on a serial console (on PC hardware at least), if you
 406	  send a BREAK and then within 5 seconds a command keypress. The
 407	  keys are documented in <file:Documentation/sysrq.txt>. Don't say Y
 408	  unless you really know what this hack does.
 409
 410config MAGIC_SYSRQ_DEFAULT_ENABLE
 411	hex "Enable magic SysRq key functions by default"
 412	depends on MAGIC_SYSRQ
 413	default 0x1
 414	help
 415	  Specifies which SysRq key functions are enabled by default.
 416	  This may be set to 1 or 0 to enable or disable them all, or
 417	  to a bitmask as described in Documentation/sysrq.txt.
 418
 419config DEBUG_KERNEL
 420	bool "Kernel debugging"
 
 
 421	help
 422	  Say Y here if you are developing drivers or trying to debug and
 423	  identify kernel problems.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 424
 425menu "Memory Debugging"
 426
 427source mm/Kconfig.debug
 428
 429config DEBUG_OBJECTS
 430	bool "Debug object operations"
 431	depends on DEBUG_KERNEL
 432	help
 433	  If you say Y here, additional code will be inserted into the
 434	  kernel to track the life time of various objects and validate
 435	  the operations on those objects.
 436
 437config DEBUG_OBJECTS_SELFTEST
 438	bool "Debug objects selftest"
 439	depends on DEBUG_OBJECTS
 440	help
 441	  This enables the selftest of the object debug code.
 442
 443config DEBUG_OBJECTS_FREE
 444	bool "Debug objects in freed memory"
 445	depends on DEBUG_OBJECTS
 446	help
 447	  This enables checks whether a k/v free operation frees an area
 448	  which contains an object which has not been deactivated
 449	  properly. This can make kmalloc/kfree-intensive workloads
 450	  much slower.
 451
 452config DEBUG_OBJECTS_TIMERS
 453	bool "Debug timer objects"
 454	depends on DEBUG_OBJECTS
 455	help
 456	  If you say Y here, additional code will be inserted into the
 457	  timer routines to track the life time of timer objects and
 458	  validate the timer operations.
 459
 460config DEBUG_OBJECTS_WORK
 461	bool "Debug work objects"
 462	depends on DEBUG_OBJECTS
 463	help
 464	  If you say Y here, additional code will be inserted into the
 465	  work queue routines to track the life time of work objects and
 466	  validate the work operations.
 467
 468config DEBUG_OBJECTS_RCU_HEAD
 469	bool "Debug RCU callbacks objects"
 470	depends on DEBUG_OBJECTS
 471	help
 472	  Enable this to turn on debugging of RCU list heads (call_rcu() usage).
 473
 474config DEBUG_OBJECTS_PERCPU_COUNTER
 475	bool "Debug percpu counter objects"
 476	depends on DEBUG_OBJECTS
 477	help
 478	  If you say Y here, additional code will be inserted into the
 479	  percpu counter routines to track the life time of percpu counter
 480	  objects and validate the percpu counter operations.
 481
 482config DEBUG_OBJECTS_ENABLE_DEFAULT
 483	int "debug_objects bootup default value (0-1)"
 484        range 0 1
 485        default "1"
 486        depends on DEBUG_OBJECTS
 487        help
 488          Debug objects boot parameter default value
 489
 490config DEBUG_SLAB
 491	bool "Debug slab memory allocations"
 492	depends on DEBUG_KERNEL && SLAB && !KMEMCHECK
 493	help
 494	  Say Y here to have the kernel do limited verification on memory
 495	  allocation as well as poisoning memory on free to catch use of freed
 496	  memory. This can make kmalloc/kfree-intensive workloads much slower.
 497
 498config DEBUG_SLAB_LEAK
 499	bool "Memory leak debugging"
 500	depends on DEBUG_SLAB
 501
 502config SLUB_DEBUG_ON
 503	bool "SLUB debugging on by default"
 504	depends on SLUB && SLUB_DEBUG && !KMEMCHECK
 505	default n
 506	help
 507	  Boot with debugging on by default. SLUB boots by default with
 508	  the runtime debug capabilities switched off. Enabling this is
 509	  equivalent to specifying the "slub_debug" parameter on boot.
 510	  There is no support for more fine grained debug control like
 511	  possible with slub_debug=xxx. SLUB debugging may be switched
 512	  off in a kernel built with CONFIG_SLUB_DEBUG_ON by specifying
 513	  "slub_debug=-".
 514
 515config SLUB_STATS
 516	default n
 517	bool "Enable SLUB performance statistics"
 518	depends on SLUB && SYSFS
 519	help
 520	  SLUB statistics are useful to debug SLUBs allocation behavior in
 521	  order find ways to optimize the allocator. This should never be
 522	  enabled for production use since keeping statistics slows down
 523	  the allocator by a few percentage points. The slabinfo command
 524	  supports the determination of the most active slabs to figure
 525	  out which slabs are relevant to a particular load.
 526	  Try running: slabinfo -DA
 527
 528config HAVE_DEBUG_KMEMLEAK
 529	bool
 530
 531config DEBUG_KMEMLEAK
 532	bool "Kernel memory leak detector"
 533	depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK
 534	select DEBUG_FS
 535	select STACKTRACE if STACKTRACE_SUPPORT
 536	select KALLSYMS
 537	select CRC32
 538	help
 539	  Say Y here if you want to enable the memory leak
 540	  detector. The memory allocation/freeing is traced in a way
 541	  similar to the Boehm's conservative garbage collector, the
 542	  difference being that the orphan objects are not freed but
 543	  only shown in /sys/kernel/debug/kmemleak. Enabling this
 544	  feature will introduce an overhead to memory
 545	  allocations. See Documentation/dev-tools/kmemleak.rst for more
 546	  details.
 547
 548	  Enabling DEBUG_SLAB or SLUB_DEBUG may increase the chances
 549	  of finding leaks due to the slab objects poisoning.
 550
 551	  In order to access the kmemleak file, debugfs needs to be
 552	  mounted (usually at /sys/kernel/debug).
 553
 554config DEBUG_KMEMLEAK_EARLY_LOG_SIZE
 555	int "Maximum kmemleak early log entries"
 556	depends on DEBUG_KMEMLEAK
 557	range 200 40000
 558	default 400
 559	help
 560	  Kmemleak must track all the memory allocations to avoid
 561	  reporting false positives. Since memory may be allocated or
 562	  freed before kmemleak is initialised, an early log buffer is
 563	  used to store these actions. If kmemleak reports "early log
 564	  buffer exceeded", please increase this value.
 565
 566config DEBUG_KMEMLEAK_TEST
 567	tristate "Simple test for the kernel memory leak detector"
 568	depends on DEBUG_KMEMLEAK && m
 569	help
 570	  This option enables a module that explicitly leaks memory.
 571
 572	  If unsure, say N.
 573
 574config DEBUG_KMEMLEAK_DEFAULT_OFF
 575	bool "Default kmemleak to off"
 576	depends on DEBUG_KMEMLEAK
 577	help
 578	  Say Y here to disable kmemleak by default. It can then be enabled
 579	  on the command line via kmemleak=on.
 
 580
 581config DEBUG_STACK_USAGE
 582	bool "Stack utilization instrumentation"
 583	depends on DEBUG_KERNEL && !IA64
 584	help
 585	  Enables the display of the minimum amount of free stack which each
 586	  task has ever had available in the sysrq-T and sysrq-P debug output.
 
 
 587
 588	  This option will slow down process creation somewhat.
 589
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 590config DEBUG_VM
 591	bool "Debug VM"
 592	depends on DEBUG_KERNEL
 593	help
 594	  Enable this to turn on extended checks in the virtual-memory system
 595          that may impact performance.
 596
 597	  If unsure, say N.
 598
 599config DEBUG_VM_VMACACHE
 600	bool "Debug VMA caching"
 601	depends on DEBUG_VM
 
 602	help
 603	  Enable this to turn on VMA caching debug information. Doing so
 604	  can cause significant overhead, so only enable it in non-production
 605	  environments.
 
 
 
 
 
 
 
 
 606
 607	  If unsure, say N.
 608
 609config DEBUG_VM_RB
 610	bool "Debug VM red-black trees"
 611	depends on DEBUG_VM
 612	help
 613	  Enable VM red-black tree debugging information and extra validations.
 614
 615	  If unsure, say N.
 616
 617config DEBUG_VM_PGFLAGS
 618	bool "Debug page-flags operations"
 619	depends on DEBUG_VM
 620	help
 621	  Enables extra validation on page flags operations.
 622
 623	  If unsure, say N.
 624
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 625config DEBUG_VIRTUAL
 626	bool "Debug VM translations"
 627	depends on DEBUG_KERNEL && X86
 628	help
 629	  Enable some costly sanity checks in virtual to page code. This can
 630	  catch mistakes with virt_to_page() and friends.
 631
 632	  If unsure, say N.
 633
 634config DEBUG_NOMMU_REGIONS
 635	bool "Debug the global anon/private NOMMU mapping region tree"
 636	depends on DEBUG_KERNEL && !MMU
 637	help
 638	  This option causes the global tree of anonymous and private mapping
 639	  regions to be regularly checked for invalid topology.
 640
 641config DEBUG_MEMORY_INIT
 642	bool "Debug memory initialisation" if EXPERT
 643	default !EXPERT
 644	help
 645	  Enable this for additional checks during memory initialisation.
 646	  The sanity checks verify aspects of the VM such as the memory model
 647	  and other information provided by the architecture. Verbose
 648	  information will be printed at KERN_DEBUG loglevel depending
 649	  on the mminit_loglevel= command-line option.
 650
 651	  If unsure, say Y
 652
 653config MEMORY_NOTIFIER_ERROR_INJECT
 654	tristate "Memory hotplug notifier error injection module"
 655	depends on MEMORY_HOTPLUG_SPARSE && NOTIFIER_ERROR_INJECTION
 656	help
 657	  This option provides the ability to inject artificial errors to
 658	  memory hotplug notifier chain callbacks.  It is controlled through
 659	  debugfs interface under /sys/kernel/debug/notifier-error-inject/memory
 660
 661	  If the notifier call chain should be failed with some events
 662	  notified, write the error code to "actions/<notifier event>/error".
 663
 664	  Example: Inject memory hotplug offline error (-12 == -ENOMEM)
 665
 666	  # cd /sys/kernel/debug/notifier-error-inject/memory
 667	  # echo -12 > actions/MEM_GOING_OFFLINE/error
 668	  # echo offline > /sys/devices/system/memory/memoryXXX/state
 669	  bash: echo: write error: Cannot allocate memory
 670
 671	  To compile this code as a module, choose M here: the module will
 672	  be called memory-notifier-error-inject.
 673
 674	  If unsure, say N.
 675
 676config DEBUG_PER_CPU_MAPS
 677	bool "Debug access to per_cpu maps"
 678	depends on DEBUG_KERNEL
 679	depends on SMP
 680	help
 681	  Say Y to verify that the per_cpu map being accessed has
 682	  been set up. This adds a fair amount of code to kernel memory
 683	  and decreases performance.
 684
 685	  Say N if unsure.
 686
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 687config DEBUG_HIGHMEM
 688	bool "Highmem debugging"
 689	depends on DEBUG_KERNEL && HIGHMEM
 
 
 690	help
 691	  This option enables additional error checking for high memory
 692	  systems.  Disable for production systems.
 693
 694config HAVE_DEBUG_STACKOVERFLOW
 695	bool
 696
 697config DEBUG_STACKOVERFLOW
 698	bool "Check for stack overflows"
 699	depends on DEBUG_KERNEL && HAVE_DEBUG_STACKOVERFLOW
 700	---help---
 701	  Say Y here if you want to check for overflows of kernel, IRQ
 702	  and exception stacks (if your architecture uses them). This
 703	  option will show detailed messages if free stack space drops
 704	  below a certain limit.
 705
 706	  These kinds of bugs usually occur when call-chains in the
 707	  kernel get too deep, especially when interrupts are
 708	  involved.
 709
 710	  Use this in cases where you see apparently random memory
 711	  corruption, especially if it appears in 'struct thread_info'
 712
 713	  If in doubt, say "N".
 714
 715source "lib/Kconfig.kmemcheck"
 716
 717source "lib/Kconfig.kasan"
 
 
 718
 719endmenu # "Memory Debugging"
 720
 721config ARCH_HAS_KCOV
 722	bool
 
 723	help
 724	  KCOV does not have any arch-specific code, but currently it is enabled
 725	  only for x86_64. KCOV requires testing on other archs, and most likely
 726	  disabling of instrumentation for some early boot code.
 
 727
 728config KCOV
 729	bool "Code coverage for fuzzing"
 730	depends on ARCH_HAS_KCOV
 731	select DEBUG_FS
 732	select GCC_PLUGINS if !COMPILE_TEST
 733	select GCC_PLUGIN_SANCOV if !COMPILE_TEST
 734	help
 735	  KCOV exposes kernel code coverage information in a form suitable
 736	  for coverage-guided fuzzing (randomized testing).
 
 737
 738	  If RANDOMIZE_BASE is enabled, PC values will not be stable across
 739	  different machines and across reboots. If you need stable PC values,
 740	  disable RANDOMIZE_BASE.
 741
 742	  For more details, see Documentation/dev-tools/kcov.rst.
 743
 744config KCOV_INSTRUMENT_ALL
 745	bool "Instrument all code by default"
 746	depends on KCOV
 747	default y if KCOV
 748	help
 749	  If you are doing generic system call fuzzing (like e.g. syzkaller),
 750	  then you will want to instrument the whole kernel and you should
 751	  say y here. If you are doing more targeted fuzzing (like e.g.
 752	  filesystem fuzzing with AFL) then you will want to enable coverage
 753	  for more specific subsets of files, and should say n here.
 754
 755config DEBUG_SHIRQ
 756	bool "Debug shared IRQ handlers"
 757	depends on DEBUG_KERNEL
 758	help
 759	  Enable this to generate a spurious interrupt as soon as a shared
 760	  interrupt handler is registered, and just before one is deregistered.
 761	  Drivers ought to be able to handle interrupts coming in at those
 762	  points; some don't and need to be caught.
 763
 764menu "Debug Lockups and Hangs"
 765
 766config LOCKUP_DETECTOR
 767	bool "Detect Hard and Soft Lockups"
 
 
 
 768	depends on DEBUG_KERNEL && !S390
 
 769	help
 770	  Say Y here to enable the kernel to act as a watchdog to detect
 771	  hard and soft lockups.
 772
 773	  Softlockups are bugs that cause the kernel to loop in kernel
 774	  mode for more than 20 seconds, without giving other tasks a
 775	  chance to run.  The current stack trace is displayed upon
 776	  detection and the system will stay locked up.
 777
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 778	  Hardlockups are bugs that cause the CPU to loop in kernel mode
 779	  for more than 10 seconds, without letting other interrupts have a
 780	  chance to run.  The current stack trace is displayed upon detection
 781	  and the system will stay locked up.
 782
 783	  The overhead should be minimal.  A periodic hrtimer runs to
 784	  generate interrupts and kick the watchdog task every 4 seconds.
 785	  An NMI is generated every 10 seconds or so to check for hardlockups.
 
 
 
 
 
 
 
 
 
 
 
 786
 787	  The frequency of hrtimer and NMI events and the soft and hard lockup
 788	  thresholds can be controlled through the sysctl watchdog_thresh.
 
 789
 790config HARDLOCKUP_DETECTOR
 791	def_bool y
 792	depends on LOCKUP_DETECTOR && !HAVE_NMI_WATCHDOG
 793	depends on PERF_EVENTS && HAVE_PERF_EVENTS_NMI
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 794
 795config BOOTPARAM_HARDLOCKUP_PANIC
 796	bool "Panic (Reboot) On Hard Lockups"
 797	depends on HARDLOCKUP_DETECTOR
 798	help
 799	  Say Y here to enable the kernel to panic on "hard lockups",
 800	  which are bugs that cause the kernel to loop in kernel
 801	  mode with interrupts disabled for more than 10 seconds (configurable
 802	  using the watchdog_thresh sysctl).
 803
 804	  Say N if unsure.
 805
 806config BOOTPARAM_HARDLOCKUP_PANIC_VALUE
 807	int
 808	depends on HARDLOCKUP_DETECTOR
 809	range 0 1
 810	default 0 if !BOOTPARAM_HARDLOCKUP_PANIC
 811	default 1 if BOOTPARAM_HARDLOCKUP_PANIC
 812
 813config BOOTPARAM_SOFTLOCKUP_PANIC
 814	bool "Panic (Reboot) On Soft Lockups"
 815	depends on LOCKUP_DETECTOR
 816	help
 817	  Say Y here to enable the kernel to panic on "soft lockups",
 818	  which are bugs that cause the kernel to loop in kernel
 819	  mode for more than 20 seconds (configurable using the watchdog_thresh
 820	  sysctl), without giving other tasks a chance to run.
 821
 822	  The panic can be used in combination with panic_timeout,
 823	  to cause the system to reboot automatically after a
 824	  lockup has been detected. This feature is useful for
 825	  high-availability systems that have uptime guarantees and
 826	  where a lockup must be resolved ASAP.
 827
 828	  Say N if unsure.
 829
 830config BOOTPARAM_SOFTLOCKUP_PANIC_VALUE
 831	int
 832	depends on LOCKUP_DETECTOR
 833	range 0 1
 834	default 0 if !BOOTPARAM_SOFTLOCKUP_PANIC
 835	default 1 if BOOTPARAM_SOFTLOCKUP_PANIC
 836
 837config DETECT_HUNG_TASK
 838	bool "Detect Hung Tasks"
 839	depends on DEBUG_KERNEL
 840	default LOCKUP_DETECTOR
 841	help
 842	  Say Y here to enable the kernel to detect "hung tasks",
 843	  which are bugs that cause the task to be stuck in
 844	  uninterruptible "D" state indefinitely.
 845
 846	  When a hung task is detected, the kernel will print the
 847	  current stack trace (which you should report), but the
 848	  task will stay in uninterruptible state. If lockdep is
 849	  enabled then all held locks will also be reported. This
 850	  feature has negligible overhead.
 851
 852config DEFAULT_HUNG_TASK_TIMEOUT
 853	int "Default timeout for hung task detection (in seconds)"
 854	depends on DETECT_HUNG_TASK
 855	default 120
 856	help
 857	  This option controls the default timeout (in seconds) used
 858	  to determine when a task has become non-responsive and should
 859	  be considered hung.
 860
 861	  It can be adjusted at runtime via the kernel.hung_task_timeout_secs
 862	  sysctl or by writing a value to
 863	  /proc/sys/kernel/hung_task_timeout_secs.
 864
 865	  A timeout of 0 disables the check.  The default is two minutes.
 866	  Keeping the default should be fine in most cases.
 867
 868config BOOTPARAM_HUNG_TASK_PANIC
 869	bool "Panic (Reboot) On Hung Tasks"
 870	depends on DETECT_HUNG_TASK
 871	help
 872	  Say Y here to enable the kernel to panic on "hung tasks",
 873	  which are bugs that cause the kernel to leave a task stuck
 874	  in uninterruptible "D" state.
 875
 876	  The panic can be used in combination with panic_timeout,
 877	  to cause the system to reboot automatically after a
 878	  hung task has been detected. This feature is useful for
 879	  high-availability systems that have uptime guarantees and
 880	  where a hung tasks must be resolved ASAP.
 881
 882	  Say N if unsure.
 883
 884config BOOTPARAM_HUNG_TASK_PANIC_VALUE
 885	int
 886	depends on DETECT_HUNG_TASK
 887	range 0 1
 888	default 0 if !BOOTPARAM_HUNG_TASK_PANIC
 889	default 1 if BOOTPARAM_HUNG_TASK_PANIC
 890
 891config WQ_WATCHDOG
 892	bool "Detect Workqueue Stalls"
 893	depends on DEBUG_KERNEL
 894	help
 895	  Say Y here to enable stall detection on workqueues.  If a
 896	  worker pool doesn't make forward progress on a pending work
 897	  item for over a given amount of time, 30s by default, a
 898	  warning message is printed along with dump of workqueue
 899	  state.  This can be configured through kernel parameter
 900	  "workqueue.watchdog_thresh" and its sysfs counterpart.
 901
 902endmenu # "Debug lockups and hangs"
 
 
 
 
 
 
 
 
 
 
 
 903
 904config PANIC_ON_OOPS
 905	bool "Panic on Oops"
 
 906	help
 907	  Say Y here to enable the kernel to panic when it oopses. This
 908	  has the same effect as setting oops=panic on the kernel command
 909	  line.
 910
 911	  This feature is useful to ensure that the kernel does not do
 912	  anything erroneous after an oops which could result in data
 913	  corruption or other issues.
 914
 915	  Say N if unsure.
 916
 917config PANIC_ON_OOPS_VALUE
 918	int
 919	range 0 1
 920	default 0 if !PANIC_ON_OOPS
 921	default 1 if PANIC_ON_OOPS
 922
 923config PANIC_TIMEOUT
 924	int "panic timeout"
 925	default 0
 926	help
 927	  Set the timeout value (in seconds) until a reboot occurs when the
 928	  the kernel panics. If n = 0, then we wait forever. A timeout
 929	  value n > 0 will wait n seconds before rebooting, while a timeout
 930	  value n < 0 will reboot immediately.
 931
 932config SCHED_DEBUG
 933	bool "Collect scheduler debugging info"
 934	depends on DEBUG_KERNEL && PROC_FS
 935	default y
 936	help
 937	  If you say Y here, the /proc/sched_debug file will be provided
 938	  that can help debug the scheduler. The runtime overhead of this
 939	  option is minimal.
 940
 941config SCHED_INFO
 942	bool
 943	default n
 944
 945config SCHEDSTATS
 946	bool "Collect scheduler statistics"
 947	depends on DEBUG_KERNEL && PROC_FS
 948	select SCHED_INFO
 949	help
 950	  If you say Y here, additional code will be inserted into the
 951	  scheduler and related routines to collect statistics about
 952	  scheduler behavior and provide them in /proc/schedstat.  These
 953	  stats may be useful for both tuning and debugging the scheduler
 954	  If you aren't debugging the scheduler or trying to tune a specific
 955	  application, you can say N to avoid the very slight overhead
 956	  this adds.
 957
 958config SCHED_STACK_END_CHECK
 959	bool "Detect stack corruption on calls to schedule()"
 960	depends on DEBUG_KERNEL
 961	default n
 962	help
 963	  This option checks for a stack overrun on calls to schedule().
 964	  If the stack end location is found to be over written always panic as
 965	  the content of the corrupted region can no longer be trusted.
 966	  This is to ensure no erroneous behaviour occurs which could result in
 967	  data corruption or a sporadic crash at a later stage once the region
 968	  is examined. The runtime overhead introduced is minimal.
 969
 970config DEBUG_TIMEKEEPING
 971	bool "Enable extra timekeeping sanity checking"
 972	help
 973	  This option will enable additional timekeeping sanity checks
 974	  which may be helpful when diagnosing issues where timekeeping
 975	  problems are suspected.
 976
 977	  This may include checks in the timekeeping hotpaths, so this
 978	  option may have a (very small) performance impact to some
 979	  workloads.
 980
 981	  If unsure, say N.
 982
 983config TIMER_STATS
 984	bool "Collect kernel timers statistics"
 985	depends on DEBUG_KERNEL && PROC_FS
 986	help
 987	  If you say Y here, additional code will be inserted into the
 988	  timer routines to collect statistics about kernel timers being
 989	  reprogrammed. The statistics can be read from /proc/timer_stats.
 990	  The statistics collection is started by writing 1 to /proc/timer_stats,
 991	  writing 0 stops it. This feature is useful to collect information
 992	  about timer usage patterns in kernel and userspace. This feature
 993	  is lightweight if enabled in the kernel config but not activated
 994	  (it defaults to deactivated on bootup and will only be activated
 995	  if some application like powertop activates it explicitly).
 996
 997config DEBUG_PREEMPT
 998	bool "Debug preemptible kernel"
 999	depends on DEBUG_KERNEL && PREEMPT && TRACE_IRQFLAGS_SUPPORT
1000	default y
1001	help
1002	  If you say Y here then the kernel will use a debug variant of the
1003	  commonly used smp_processor_id() function and will print warnings
1004	  if kernel code uses it in a preemption-unsafe way. Also, the kernel
1005	  will detect preemption count underflows.
1006
1007menu "Lock Debugging (spinlocks, mutexes, etc...)"
1008
1009config DEBUG_RT_MUTEXES
1010	bool "RT Mutex debugging, deadlock detection"
1011	depends on DEBUG_KERNEL && RT_MUTEXES
1012	help
1013	 This allows rt mutex semantics violations and rt mutex related
1014	 deadlocks (lockups) to be detected and reported automatically.
1015
1016config DEBUG_SPINLOCK
1017	bool "Spinlock and rw-lock debugging: basic checks"
1018	depends on DEBUG_KERNEL
1019	select UNINLINE_SPIN_UNLOCK
1020	help
1021	  Say Y here and build SMP to catch missing spinlock initialization
1022	  and certain other kinds of spinlock errors commonly made.  This is
1023	  best used in conjunction with the NMI watchdog so that spinlock
1024	  deadlocks are also debuggable.
1025
1026config DEBUG_MUTEXES
1027	bool "Mutex debugging: basic checks"
1028	depends on DEBUG_KERNEL
1029	help
1030	 This feature allows mutex semantics violations to be detected and
1031	 reported.
1032
1033config DEBUG_WW_MUTEX_SLOWPATH
1034	bool "Wait/wound mutex debugging: Slowpath testing"
1035	depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
1036	select DEBUG_LOCK_ALLOC
1037	select DEBUG_SPINLOCK
1038	select DEBUG_MUTEXES
1039	help
1040	 This feature enables slowpath testing for w/w mutex users by
1041	 injecting additional -EDEADLK wound/backoff cases. Together with
1042	 the full mutex checks enabled with (CONFIG_PROVE_LOCKING) this
1043	 will test all possible w/w mutex interface abuse with the
1044	 exception of simply not acquiring all the required locks.
1045	 Note that this feature can introduce significant overhead, so
1046	 it really should not be enabled in a production or distro kernel,
1047	 even a debug kernel.  If you are a driver writer, enable it.  If
1048	 you are a distro, do not.
1049
1050config DEBUG_LOCK_ALLOC
1051	bool "Lock debugging: detect incorrect freeing of live locks"
1052	depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
1053	select DEBUG_SPINLOCK
1054	select DEBUG_MUTEXES
1055	select LOCKDEP
1056	help
1057	 This feature will check whether any held lock (spinlock, rwlock,
1058	 mutex or rwsem) is incorrectly freed by the kernel, via any of the
1059	 memory-freeing routines (kfree(), kmem_cache_free(), free_pages(),
1060	 vfree(), etc.), whether a live lock is incorrectly reinitialized via
1061	 spin_lock_init()/mutex_init()/etc., or whether there is any lock
1062	 held during task exit.
1063
1064config PROVE_LOCKING
1065	bool "Lock debugging: prove locking correctness"
1066	depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
1067	select LOCKDEP
1068	select DEBUG_SPINLOCK
1069	select DEBUG_MUTEXES
 
 
 
1070	select DEBUG_LOCK_ALLOC
 
1071	select TRACE_IRQFLAGS
1072	default n
1073	help
1074	 This feature enables the kernel to prove that all locking
1075	 that occurs in the kernel runtime is mathematically
1076	 correct: that under no circumstance could an arbitrary (and
1077	 not yet triggered) combination of observed locking
1078	 sequences (on an arbitrary number of CPUs, running an
1079	 arbitrary number of tasks and interrupt contexts) cause a
1080	 deadlock.
1081
1082	 In short, this feature enables the kernel to report locking
1083	 related deadlocks before they actually occur.
1084
1085	 The proof does not depend on how hard and complex a
1086	 deadlock scenario would be to trigger: how many
1087	 participant CPUs, tasks and irq-contexts would be needed
1088	 for it to trigger. The proof also does not depend on
1089	 timing: if a race and a resulting deadlock is possible
1090	 theoretically (no matter how unlikely the race scenario
1091	 is), it will be proven so and will immediately be
1092	 reported by the kernel (once the event is observed that
1093	 makes the deadlock theoretically possible).
1094
1095	 If a deadlock is impossible (i.e. the locking rules, as
1096	 observed by the kernel, are mathematically correct), the
1097	 kernel reports nothing.
1098
1099	 NOTE: this feature can also be enabled for rwlocks, mutexes
1100	 and rwsems - in which case all dependencies between these
1101	 different locking variants are observed and mapped too, and
1102	 the proof of observed correctness is also maintained for an
1103	 arbitrary combination of these separate locking variants.
1104
1105	 For more details, see Documentation/locking/lockdep-design.txt.
1106
1107config PROVE_LOCKING_SMALL
1108	bool
 
 
 
 
 
 
1109
1110config LOCKDEP
1111	bool
1112	depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
1113	select STACKTRACE
1114	select FRAME_POINTER if !MIPS && !PPC && !ARM_UNWIND && !S390 && !MICROBLAZE && !ARC && !SCORE
1115	select KALLSYMS
1116	select KALLSYMS_ALL
1117
1118config LOCK_STAT
1119	bool "Lock usage statistics"
1120	depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
1121	select LOCKDEP
1122	select DEBUG_SPINLOCK
1123	select DEBUG_MUTEXES
 
1124	select DEBUG_LOCK_ALLOC
1125	default n
1126	help
1127	 This feature enables tracking lock contention points
1128
1129	 For more details, see Documentation/locking/lockstat.txt
1130
1131	 This also enables lock events required by "perf lock",
1132	 subcommand of perf.
1133	 If you want to use "perf lock", you also need to turn on
1134	 CONFIG_EVENT_TRACING.
1135
1136	 CONFIG_LOCK_STAT defines "contended" and "acquired" lock events.
1137	 (CONFIG_LOCKDEP defines "acquire" and "release" events.)
1138
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1139config DEBUG_LOCKDEP
1140	bool "Lock dependency engine debugging"
1141	depends on DEBUG_KERNEL && LOCKDEP
 
1142	help
1143	  If you say Y here, the lock dependency engine will do
1144	  additional runtime checks to debug itself, at the price
1145	  of more runtime overhead.
1146
1147config DEBUG_ATOMIC_SLEEP
1148	bool "Sleep inside atomic section checking"
1149	select PREEMPT_COUNT
1150	depends on DEBUG_KERNEL
 
1151	help
1152	  If you say Y here, various routines which may sleep will become very
1153	  noisy if they are called inside atomic sections: when a spinlock is
1154	  held, inside an rcu read side critical section, inside preempt disabled
1155	  sections, inside an interrupt, etc...
1156
1157config DEBUG_LOCKING_API_SELFTESTS
1158	bool "Locking API boot-time self-tests"
1159	depends on DEBUG_KERNEL
1160	help
1161	  Say Y here if you want the kernel to run a short self-test during
1162	  bootup. The self-test checks whether common types of locking bugs
1163	  are detected by debugging mechanisms or not. (if you disable
1164	  lock debugging then those bugs wont be detected of course.)
1165	  The following locking APIs are covered: spinlocks, rwlocks,
1166	  mutexes and rwsems.
1167
1168config LOCK_TORTURE_TEST
1169	tristate "torture tests for locking"
1170	depends on DEBUG_KERNEL
1171	select TORTURE_TEST
1172	default n
1173	help
1174	  This option provides a kernel module that runs torture tests
1175	  on kernel locking primitives.  The kernel module may be built
1176	  after the fact on the running kernel to be tested, if desired.
1177
1178	  Say Y here if you want kernel locking-primitive torture tests
1179	  to be built into the kernel.
1180	  Say M if you want these torture tests to build as a module.
1181	  Say N if you are unsure.
1182
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1183endmenu # lock debugging
1184
1185config TRACE_IRQFLAGS
 
1186	bool
1187	help
1188	  Enables hooks to interrupt enabling and disabling for
1189	  either tracing or lock debugging.
1190
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1191config STACKTRACE
1192	bool "Stack backtrace support"
1193	depends on STACKTRACE_SUPPORT
1194	help
1195	  This option causes the kernel to create a /proc/pid/stack for
1196	  every process, showing its current stack trace.
1197	  It is also used by various kernel debugging features that require
1198	  stack trace generation.
1199
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1200config DEBUG_KOBJECT
1201	bool "kobject debugging"
1202	depends on DEBUG_KERNEL
1203	help
1204	  If you say Y here, some extra kobject debugging messages will be sent
1205	  to the syslog. 
1206
1207config DEBUG_KOBJECT_RELEASE
1208	bool "kobject release debugging"
1209	depends on DEBUG_OBJECTS_TIMERS
1210	help
1211	  kobjects are reference counted objects.  This means that their
1212	  last reference count put is not predictable, and the kobject can
1213	  live on past the point at which a driver decides to drop it's
1214	  initial reference to the kobject gained on allocation.  An
1215	  example of this would be a struct device which has just been
1216	  unregistered.
1217
1218	  However, some buggy drivers assume that after such an operation,
1219	  the memory backing the kobject can be immediately freed.  This
1220	  goes completely against the principles of a refcounted object.
1221
1222	  If you say Y here, the kernel will delay the release of kobjects
1223	  on the last reference count to improve the visibility of this
1224	  kind of kobject release bug.
1225
1226config HAVE_DEBUG_BUGVERBOSE
1227	bool
1228
1229config DEBUG_BUGVERBOSE
1230	bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
1231	depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
1232	default y
1233	help
1234	  Say Y here to make BUG() panics output the file name and line number
1235	  of the BUG call as well as the EIP and oops trace.  This aids
1236	  debugging but costs about 70-100K of memory.
1237
1238config DEBUG_LIST
1239	bool "Debug linked list manipulation"
1240	depends on DEBUG_KERNEL || BUG_ON_DATA_CORRUPTION
 
1241	help
1242	  Enable this to turn on extended checks in the linked-list
1243	  walking routines.
 
 
 
 
1244
1245	  If unsure, say N.
1246
1247config DEBUG_PI_LIST
1248	bool "Debug priority linked list manipulation"
1249	depends on DEBUG_KERNEL
1250	help
1251	  Enable this to turn on extended checks in the priority-ordered
1252	  linked-list (plist) walking routines.  This checks the entire
1253	  list multiple times during each manipulation.
1254
1255	  If unsure, say N.
1256
1257config DEBUG_SG
1258	bool "Debug SG table operations"
1259	depends on DEBUG_KERNEL
1260	help
1261	  Enable this to turn on checks on scatter-gather tables. This can
1262	  help find problems with drivers that do not properly initialize
1263	  their sg tables.
1264
1265	  If unsure, say N.
1266
1267config DEBUG_NOTIFIERS
1268	bool "Debug notifier call chains"
1269	depends on DEBUG_KERNEL
1270	help
1271	  Enable this to turn on sanity checking for notifier call chains.
1272	  This is most useful for kernel developers to make sure that
1273	  modules properly unregister themselves from notifier chains.
1274	  This is a relatively cheap check but if you care about maximum
1275	  performance, say N.
1276
1277config DEBUG_CREDENTIALS
1278	bool "Debug credential management"
1279	depends on DEBUG_KERNEL
1280	help
1281	  Enable this to turn on some debug checking for credential
1282	  management.  The additional code keeps track of the number of
1283	  pointers from task_structs to any given cred struct, and checks to
1284	  see that this number never exceeds the usage count of the cred
1285	  struct.
1286
1287	  Furthermore, if SELinux is enabled, this also checks that the
1288	  security pointer in the cred struct is never seen to be invalid.
1289
1290	  If unsure, say N.
1291
1292menu "RCU Debugging"
1293
1294config PROVE_RCU
1295	def_bool PROVE_LOCKING
1296
1297config PROVE_RCU_REPEATEDLY
1298	bool "RCU debugging: don't disable PROVE_RCU on first splat"
1299	depends on PROVE_RCU
1300	default n
1301	help
1302	 By itself, PROVE_RCU will disable checking upon issuing the
1303	 first warning (or "splat").  This feature prevents such
1304	 disabling, allowing multiple RCU-lockdep warnings to be printed
1305	 on a single reboot.
1306
1307	 Say Y to allow multiple RCU-lockdep warnings per boot.
1308
1309	 Say N if you are unsure.
1310
1311config SPARSE_RCU_POINTER
1312	bool "RCU debugging: sparse-based checks for pointer usage"
1313	default n
1314	help
1315	 This feature enables the __rcu sparse annotation for
1316	 RCU-protected pointers.  This annotation will cause sparse
1317	 to flag any non-RCU used of annotated pointers.  This can be
1318	 helpful when debugging RCU usage.  Please note that this feature
1319	 is not intended to enforce code cleanliness; it is instead merely
1320	 a debugging aid.
1321
1322	 Say Y to make sparse flag questionable use of RCU-protected pointers
1323
1324	 Say N if you are unsure.
1325
1326config TORTURE_TEST
1327	tristate
1328	default n
1329
1330config RCU_PERF_TEST
1331	tristate "performance tests for RCU"
1332	depends on DEBUG_KERNEL
1333	select TORTURE_TEST
1334	select SRCU
1335	select TASKS_RCU
1336	default n
1337	help
1338	  This option provides a kernel module that runs performance
1339	  tests on the RCU infrastructure.  The kernel module may be built
1340	  after the fact on the running kernel to be tested, if desired.
1341
1342	  Say Y here if you want RCU performance tests to be built into
1343	  the kernel.
1344	  Say M if you want the RCU performance tests to build as a module.
1345	  Say N if you are unsure.
1346
1347config RCU_TORTURE_TEST
1348	tristate "torture tests for RCU"
1349	depends on DEBUG_KERNEL
1350	select TORTURE_TEST
1351	select SRCU
1352	select TASKS_RCU
1353	default n
1354	help
1355	  This option provides a kernel module that runs torture tests
1356	  on the RCU infrastructure.  The kernel module may be built
1357	  after the fact on the running kernel to be tested, if desired.
1358
1359	  Say Y here if you want RCU torture tests to be built into
1360	  the kernel.
1361	  Say M if you want the RCU torture tests to build as a module.
1362	  Say N if you are unsure.
1363
1364config RCU_TORTURE_TEST_SLOW_PREINIT
1365	bool "Slow down RCU grace-period pre-initialization to expose races"
1366	depends on RCU_TORTURE_TEST
1367	help
1368	  This option delays grace-period pre-initialization (the
1369	  propagation of CPU-hotplug changes up the rcu_node combining
1370	  tree) for a few jiffies between initializing each pair of
1371	  consecutive rcu_node structures.  This helps to expose races
1372	  involving grace-period pre-initialization, in other words, it
1373	  makes your kernel less stable.  It can also greatly increase
1374	  grace-period latency, especially on systems with large numbers
1375	  of CPUs.  This is useful when torture-testing RCU, but in
1376	  almost no other circumstance.
1377
1378	  Say Y here if you want your system to crash and hang more often.
1379	  Say N if you want a sane system.
1380
1381config RCU_TORTURE_TEST_SLOW_PREINIT_DELAY
1382	int "How much to slow down RCU grace-period pre-initialization"
1383	range 0 5
1384	default 3
1385	depends on RCU_TORTURE_TEST_SLOW_PREINIT
1386	help
1387	  This option specifies the number of jiffies to wait between
1388	  each rcu_node structure pre-initialization step.
1389
1390config RCU_TORTURE_TEST_SLOW_INIT
1391	bool "Slow down RCU grace-period initialization to expose races"
1392	depends on RCU_TORTURE_TEST
1393	help
1394	  This option delays grace-period initialization for a few
1395	  jiffies between initializing each pair of consecutive
1396	  rcu_node structures.	This helps to expose races involving
1397	  grace-period initialization, in other words, it makes your
1398	  kernel less stable.  It can also greatly increase grace-period
1399	  latency, especially on systems with large numbers of CPUs.
1400	  This is useful when torture-testing RCU, but in almost no
1401	  other circumstance.
1402
1403	  Say Y here if you want your system to crash and hang more often.
1404	  Say N if you want a sane system.
1405
1406config RCU_TORTURE_TEST_SLOW_INIT_DELAY
1407	int "How much to slow down RCU grace-period initialization"
1408	range 0 5
1409	default 3
1410	depends on RCU_TORTURE_TEST_SLOW_INIT
1411	help
1412	  This option specifies the number of jiffies to wait between
1413	  each rcu_node structure initialization.
1414
1415config RCU_TORTURE_TEST_SLOW_CLEANUP
1416	bool "Slow down RCU grace-period cleanup to expose races"
1417	depends on RCU_TORTURE_TEST
1418	help
1419	  This option delays grace-period cleanup for a few jiffies
1420	  between cleaning up each pair of consecutive rcu_node
1421	  structures.  This helps to expose races involving grace-period
1422	  cleanup, in other words, it makes your kernel less stable.
1423	  It can also greatly increase grace-period latency, especially
1424	  on systems with large numbers of CPUs.  This is useful when
1425	  torture-testing RCU, but in almost no other circumstance.
1426
1427	  Say Y here if you want your system to crash and hang more often.
1428	  Say N if you want a sane system.
1429
1430config RCU_TORTURE_TEST_SLOW_CLEANUP_DELAY
1431	int "How much to slow down RCU grace-period cleanup"
1432	range 0 5
1433	default 3
1434	depends on RCU_TORTURE_TEST_SLOW_CLEANUP
1435	help
1436	  This option specifies the number of jiffies to wait between
1437	  each rcu_node structure cleanup operation.
1438
1439config RCU_CPU_STALL_TIMEOUT
1440	int "RCU CPU stall timeout in seconds"
1441	depends on RCU_STALL_COMMON
1442	range 3 300
1443	default 21
1444	help
1445	  If a given RCU grace period extends more than the specified
1446	  number of seconds, a CPU stall warning is printed.  If the
1447	  RCU grace period persists, additional CPU stall warnings are
1448	  printed at more widely spaced intervals.
1449
1450config RCU_TRACE
1451	bool "Enable tracing for RCU"
1452	depends on DEBUG_KERNEL
1453	select TRACE_CLOCK
1454	help
1455	  This option provides tracing in RCU which presents stats
1456	  in debugfs for debugging RCU implementation.  It also enables
1457	  additional tracepoints for ftrace-style event tracing.
1458
1459	  Say Y here if you want to enable RCU tracing
1460	  Say N if you are unsure.
1461
1462config RCU_EQS_DEBUG
1463	bool "Provide debugging asserts for adding NO_HZ support to an arch"
1464	depends on DEBUG_KERNEL
1465	help
1466	  This option provides consistency checks in RCU's handling of
1467	  NO_HZ.  These checks have proven quite helpful in detecting
1468	  bugs in arch-specific NO_HZ code.
1469
1470	  Say N here if you need ultimate kernel/user switch latencies
1471	  Say Y if you are unsure
1472
1473endmenu # "RCU Debugging"
1474
1475config DEBUG_WQ_FORCE_RR_CPU
1476	bool "Force round-robin CPU selection for unbound work items"
1477	depends on DEBUG_KERNEL
1478	default n
1479	help
1480	  Workqueue used to implicitly guarantee that work items queued
1481	  without explicit CPU specified are put on the local CPU.  This
1482	  guarantee is no longer true and while local CPU is still
1483	  preferred work items may be put on foreign CPUs.  Kernel
1484	  parameter "workqueue.debug_force_rr_cpu" is added to force
1485	  round-robin CPU selection to flush out usages which depend on the
1486	  now broken guarantee.  This config option enables the debug
1487	  feature by default.  When enabled, memory and cache locality will
1488	  be impacted.
1489
1490config DEBUG_BLOCK_EXT_DEVT
1491        bool "Force extended block device numbers and spread them"
1492	depends on DEBUG_KERNEL
1493	depends on BLOCK
1494	default n
1495	help
1496	  BIG FAT WARNING: ENABLING THIS OPTION MIGHT BREAK BOOTING ON
1497	  SOME DISTRIBUTIONS.  DO NOT ENABLE THIS UNLESS YOU KNOW WHAT
1498	  YOU ARE DOING.  Distros, please enable this and fix whatever
1499	  is broken.
1500
1501	  Conventionally, block device numbers are allocated from
1502	  predetermined contiguous area.  However, extended block area
1503	  may introduce non-contiguous block device numbers.  This
1504	  option forces most block device numbers to be allocated from
1505	  the extended space and spreads them to discover kernel or
1506	  userland code paths which assume predetermined contiguous
1507	  device number allocation.
1508
1509	  Note that turning on this debug option shuffles all the
1510	  device numbers for all IDE and SCSI devices including libata
1511	  ones, so root partition specified using device number
1512	  directly (via rdev or root=MAJ:MIN) won't work anymore.
1513	  Textual device names (root=/dev/sdXn) will continue to work.
1514
1515	  Say N if you are unsure.
1516
1517config CPU_HOTPLUG_STATE_CONTROL
1518	bool "Enable CPU hotplug state control"
1519	depends on DEBUG_KERNEL
1520	depends on HOTPLUG_CPU
1521	default n
1522	help
1523	  Allows to write steps between "offline" and "online" to the CPUs
1524	  sysfs target file so states can be stepped granular. This is a debug
1525	  option for now as the hotplug machinery cannot be stopped and
1526	  restarted at arbitrary points yet.
1527
1528	  Say N if your are unsure.
1529
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1530config NOTIFIER_ERROR_INJECTION
1531	tristate "Notifier error injection"
1532	depends on DEBUG_KERNEL
1533	select DEBUG_FS
1534	help
1535	  This option provides the ability to inject artificial errors to
1536	  specified notifier chain callbacks. It is useful to test the error
1537	  handling of notifier call chain failures.
1538
1539	  Say N if unsure.
1540
1541config PM_NOTIFIER_ERROR_INJECT
1542	tristate "PM notifier error injection module"
1543	depends on PM && NOTIFIER_ERROR_INJECTION
1544	default m if PM_DEBUG
1545	help
1546	  This option provides the ability to inject artificial errors to
1547	  PM notifier chain callbacks.  It is controlled through debugfs
1548	  interface /sys/kernel/debug/notifier-error-inject/pm
1549
1550	  If the notifier call chain should be failed with some events
1551	  notified, write the error code to "actions/<notifier event>/error".
1552
1553	  Example: Inject PM suspend error (-12 = -ENOMEM)
1554
1555	  # cd /sys/kernel/debug/notifier-error-inject/pm/
1556	  # echo -12 > actions/PM_SUSPEND_PREPARE/error
1557	  # echo mem > /sys/power/state
1558	  bash: echo: write error: Cannot allocate memory
1559
1560	  To compile this code as a module, choose M here: the module will
1561	  be called pm-notifier-error-inject.
1562
1563	  If unsure, say N.
1564
1565config OF_RECONFIG_NOTIFIER_ERROR_INJECT
1566	tristate "OF reconfig notifier error injection module"
1567	depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION
1568	help
1569	  This option provides the ability to inject artificial errors to
1570	  OF reconfig notifier chain callbacks.  It is controlled
1571	  through debugfs interface under
1572	  /sys/kernel/debug/notifier-error-inject/OF-reconfig/
1573
1574	  If the notifier call chain should be failed with some events
1575	  notified, write the error code to "actions/<notifier event>/error".
1576
1577	  To compile this code as a module, choose M here: the module will
1578	  be called of-reconfig-notifier-error-inject.
1579
1580	  If unsure, say N.
1581
1582config NETDEV_NOTIFIER_ERROR_INJECT
1583	tristate "Netdev notifier error injection module"
1584	depends on NET && NOTIFIER_ERROR_INJECTION
1585	help
1586	  This option provides the ability to inject artificial errors to
1587	  netdevice notifier chain callbacks.  It is controlled through debugfs
1588	  interface /sys/kernel/debug/notifier-error-inject/netdev
1589
1590	  If the notifier call chain should be failed with some events
1591	  notified, write the error code to "actions/<notifier event>/error".
1592
1593	  Example: Inject netdevice mtu change error (-22 = -EINVAL)
1594
1595	  # cd /sys/kernel/debug/notifier-error-inject/netdev
1596	  # echo -22 > actions/NETDEV_CHANGEMTU/error
1597	  # ip link set eth0 mtu 1024
1598	  RTNETLINK answers: Invalid argument
1599
1600	  To compile this code as a module, choose M here: the module will
1601	  be called netdev-notifier-error-inject.
1602
1603	  If unsure, say N.
1604
 
 
 
 
 
 
 
 
 
 
1605config FAULT_INJECTION
1606	bool "Fault-injection framework"
1607	depends on DEBUG_KERNEL
1608	help
1609	  Provide fault-injection framework.
1610	  For more details, see Documentation/fault-injection/.
1611
1612config FAILSLAB
1613	bool "Fault-injection capability for kmalloc"
1614	depends on FAULT_INJECTION
1615	depends on SLAB || SLUB
1616	help
1617	  Provide fault-injection capability for kmalloc.
1618
1619config FAIL_PAGE_ALLOC
1620	bool "Fault-injection capabilitiy for alloc_pages()"
1621	depends on FAULT_INJECTION
1622	help
1623	  Provide fault-injection capability for alloc_pages().
1624
 
 
 
 
 
 
 
1625config FAIL_MAKE_REQUEST
1626	bool "Fault-injection capability for disk IO"
1627	depends on FAULT_INJECTION && BLOCK
1628	help
1629	  Provide fault-injection capability for disk IO.
1630
1631config FAIL_IO_TIMEOUT
1632	bool "Fault-injection capability for faking disk interrupts"
1633	depends on FAULT_INJECTION && BLOCK
1634	help
1635	  Provide fault-injection capability on end IO handling. This
1636	  will make the block layer "forget" an interrupt as configured,
1637	  thus exercising the error handling.
1638
1639	  Only works with drivers that use the generic timeout handling,
1640	  for others it wont do anything.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1641
1642config FAIL_MMC_REQUEST
1643	bool "Fault-injection capability for MMC IO"
1644	depends on FAULT_INJECTION_DEBUG_FS && MMC
1645	help
1646	  Provide fault-injection capability for MMC IO.
1647	  This will make the mmc core return data errors. This is
1648	  useful to test the error handling in the mmc block device
1649	  and to test how the mmc host driver handles retries from
1650	  the block device.
1651
1652config FAIL_FUTEX
1653	bool "Fault-injection capability for futexes"
1654	select DEBUG_FS
1655	depends on FAULT_INJECTION && FUTEX
1656	help
1657	  Provide fault-injection capability for futexes.
 
1658
1659config FAULT_INJECTION_DEBUG_FS
1660	bool "Debugfs entries for fault-injection capabilities"
1661	depends on FAULT_INJECTION && SYSFS && DEBUG_FS
 
1662	help
1663	  Enable configuration of fault-injection capabilities via debugfs.
 
 
 
 
1664
1665config FAULT_INJECTION_STACKTRACE_FILTER
1666	bool "stacktrace filter for fault-injection capabilities"
1667	depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT
1668	depends on !X86_64
1669	select STACKTRACE
1670	select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND && !ARC && !SCORE
1671	help
1672	  Provide stacktrace filter for fault-injection capabilities
1673
1674config LATENCYTOP
1675	bool "Latency measuring infrastructure"
1676	depends on DEBUG_KERNEL
1677	depends on STACKTRACE_SUPPORT
1678	depends on PROC_FS
1679	select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND && !ARC
1680	select KALLSYMS
1681	select KALLSYMS_ALL
1682	select STACKTRACE
1683	select SCHEDSTATS
1684	select SCHED_DEBUG
1685	help
1686	  Enable this option if you want to use the LatencyTOP tool
1687	  to find out which userspace is blocking on what kernel operations.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1688
1689source kernel/trace/Kconfig
1690
1691menu "Runtime Testing"
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1692
1693config LKDTM
1694	tristate "Linux Kernel Dump Test Tool Module"
1695	depends on DEBUG_FS
1696	depends on BLOCK
1697	default n
1698	help
1699	This module enables testing of the different dumping mechanisms by
1700	inducing system failures at predefined crash points.
1701	If you don't need it: say N
1702	Choose M here to compile this code as a module. The module will be
1703	called lkdtm.
1704
1705	Documentation on how to use the module can be found in
1706	Documentation/fault-injection/provoke-crashes.txt
 
 
 
 
 
 
 
 
 
 
 
 
1707
1708config TEST_LIST_SORT
1709	bool "Linked list sorting test"
1710	depends on DEBUG_KERNEL
 
1711	help
1712	  Enable this to turn on 'list_sort()' function test. This test is
1713	  executed only once during system boot, so affects only boot time.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1714
1715	  If unsure, say N.
1716
1717config KPROBES_SANITY_TEST
1718	bool "Kprobes sanity tests"
1719	depends on DEBUG_KERNEL
1720	depends on KPROBES
1721	default n
 
 
1722	help
1723	  This option provides for testing basic kprobes functionality on
1724	  boot. A sample kprobe, jprobe and kretprobe are inserted and
1725	  verified for functionality.
1726
1727	  Say N if you are unsure.
1728
 
 
 
 
 
 
 
 
 
 
 
 
1729config BACKTRACE_SELF_TEST
1730	tristate "Self test for the backtrace code"
1731	depends on DEBUG_KERNEL
1732	default n
1733	help
1734	  This option provides a kernel module that can be used to test
1735	  the kernel stack backtrace code. This option is not useful
1736	  for distributions or general kernels, but only for kernel
1737	  developers working on architecture code.
1738
1739	  Note that if you want to also test saved backtraces, you will
1740	  have to enable STACKTRACE as well.
1741
1742	  Say N if you are unsure.
1743
 
 
 
 
 
 
 
 
 
 
1744config RBTREE_TEST
1745	tristate "Red-Black tree test"
1746	depends on DEBUG_KERNEL
1747	help
1748	  A benchmark measuring the performance of the rbtree library.
1749	  Also includes rbtree invariant checks.
1750
 
 
 
 
 
 
 
 
 
 
 
 
1751config INTERVAL_TREE_TEST
1752	tristate "Interval tree test"
1753	depends on m && DEBUG_KERNEL
1754	select INTERVAL_TREE
1755	help
1756	  A benchmark measuring the performance of the interval tree library
1757
1758config PERCPU_TEST
1759	tristate "Per cpu operations test"
1760	depends on m && DEBUG_KERNEL
1761	help
1762	  Enable this option to build test module which validates per-cpu
1763	  operations.
1764
1765	  If unsure, say N.
1766
1767config ATOMIC64_SELFTEST
1768	bool "Perform an atomic64_t self-test at boot"
1769	help
1770	  Enable this option to test the atomic64_t functions at boot.
 
1771
1772	  If unsure, say N.
1773
1774config ASYNC_RAID6_TEST
1775	tristate "Self test for hardware accelerated raid6 recovery"
1776	depends on ASYNC_RAID6_RECOV
1777	select ASYNC_MEMCPY
1778	---help---
1779	  This is a one-shot self test that permutes through the
1780	  recovery of all the possible two disk failure scenarios for a
1781	  N-disk array.  Recovery is performed with the asynchronous
1782	  raid6 recovery routines, and will optionally use an offload
1783	  engine if one is available.
1784
1785	  If unsure, say N.
1786
1787config TEST_HEXDUMP
1788	tristate "Test functions located in the hexdump module at runtime"
1789
1790config TEST_STRING_HELPERS
1791	tristate "Test functions located in the string_helpers module at runtime"
 
 
 
 
 
 
 
1792
1793config TEST_KSTRTOX
1794	tristate "Test kstrto*() family of functions at runtime"
1795
1796config TEST_PRINTF
1797	tristate "Test printf() family of functions at runtime"
1798
 
 
 
1799config TEST_BITMAP
1800	tristate "Test bitmap_*() family of functions at runtime"
1801	default n
1802	help
1803	  Enable this option to test the bitmap functions at boot.
1804
1805	  If unsure, say N.
1806
1807config TEST_UUID
1808	tristate "Test functions located in the uuid module at runtime"
1809
 
 
 
 
 
 
 
 
 
 
 
 
1810config TEST_RHASHTABLE
1811	tristate "Perform selftest on resizable hash table"
1812	default n
1813	help
1814	  Enable this option to test the rhashtable functions at boot.
1815
1816	  If unsure, say N.
1817
1818config TEST_HASH
1819	tristate "Perform selftest on hash functions"
1820	default n
 
 
 
1821	help
1822	  Enable this option to test the kernel's integer (<linux/hash,h>)
1823	  and string (<linux/stringhash.h>) hash functions on boot
1824	  (or module load).
1825
1826	  This is intended to help people writing architecture-specific
1827	  optimized versions.  If unsure, say N.
1828
1829endmenu # runtime tests
1830
1831config PROVIDE_OHCI1394_DMA_INIT
1832	bool "Remote debugging over FireWire early on boot"
1833	depends on PCI && X86
1834	help
1835	  If you want to debug problems which hang or crash the kernel early
1836	  on boot and the crashing machine has a FireWire port, you can use
1837	  this feature to remotely access the memory of the crashed machine
1838	  over FireWire. This employs remote DMA as part of the OHCI1394
1839	  specification which is now the standard for FireWire controllers.
1840
1841	  With remote DMA, you can monitor the printk buffer remotely using
1842	  firescope and access all memory below 4GB using fireproxy from gdb.
1843	  Even controlling a kernel debugger is possible using remote DMA.
1844
1845	  Usage:
1846
1847	  If ohci1394_dma=early is used as boot parameter, it will initialize
1848	  all OHCI1394 controllers which are found in the PCI config space.
1849
1850	  As all changes to the FireWire bus such as enabling and disabling
1851	  devices cause a bus reset and thereby disable remote DMA for all
1852	  devices, be sure to have the cable plugged and FireWire enabled on
1853	  the debugging host before booting the debug target for debugging.
1854
1855	  This code (~1k) is freed after boot. By then, the firewire stack
1856	  in charge of the OHCI-1394 controllers should be used instead.
1857
1858	  See Documentation/debugging-via-ohci1394.txt for more information.
1859
1860config DMA_API_DEBUG
1861	bool "Enable debugging of DMA-API usage"
1862	depends on HAVE_DMA_API_DEBUG
1863	help
1864	  Enable this option to debug the use of the DMA API by device drivers.
1865	  With this option you will be able to detect common bugs in device
1866	  drivers like double-freeing of DMA mappings or freeing mappings that
1867	  were never allocated.
1868
1869	  This also attempts to catch cases where a page owned by DMA is
1870	  accessed by the cpu in a way that could cause data corruption.  For
1871	  example, this enables cow_user_page() to check that the source page is
1872	  not undergoing DMA.
1873
1874	  This option causes a performance degradation.  Use only if you want to
1875	  debug device drivers and dma interactions.
1876
1877	  If unsure, say N.
1878
1879config TEST_LKM
1880	tristate "Test module loading with 'hello world' module"
1881	default n
1882	depends on m
1883	help
1884	  This builds the "test_module" module that emits "Hello, world"
1885	  on printk when loaded. It is designed to be used for basic
1886	  evaluation of the module loading subsystem (for example when
1887	  validating module verification). It lacks any extra dependencies,
1888	  and will not normally be loaded by the system unless explicitly
1889	  requested by name.
1890
1891	  If unsure, say N.
1892
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1893config TEST_USER_COPY
1894	tristate "Test user/kernel boundary protections"
1895	default n
1896	depends on m
1897	help
1898	  This builds the "test_user_copy" module that runs sanity checks
1899	  on the copy_to/from_user infrastructure, making sure basic
1900	  user/kernel boundary testing is working. If it fails to load,
1901	  a regression has been detected in the user/kernel memory boundary
1902	  protections.
1903
1904	  If unsure, say N.
1905
1906config TEST_BPF
1907	tristate "Test BPF filter functionality"
1908	default n
1909	depends on m && NET
1910	help
1911	  This builds the "test_bpf" module that runs various test vectors
1912	  against the BPF interpreter or BPF JIT compiler depending on the
1913	  current setting. This is in particular useful for BPF JIT compiler
1914	  development, but also to run regression tests against changes in
1915	  the interpreter code. It also enables test stubs for eBPF maps and
1916	  verifier used by user space verifier testsuite.
1917
1918	  If unsure, say N.
1919
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1920config TEST_FIRMWARE
1921	tristate "Test firmware loading via userspace interface"
1922	default n
1923	depends on FW_LOADER
1924	help
1925	  This builds the "test_firmware" module that creates a userspace
1926	  interface for testing firmware loading. This can be used to
1927	  control the triggering of firmware loading without needing an
1928	  actual firmware-using device. The contents can be rechecked by
1929	  userspace.
1930
1931	  If unsure, say N.
1932
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1933config TEST_UDELAY
1934	tristate "udelay test driver"
1935	default n
1936	help
1937	  This builds the "udelay_test" module that helps to make sure
1938	  that udelay() is working properly.
1939
1940	  If unsure, say N.
1941
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1942config MEMTEST
1943	bool "Memtest"
1944	depends on HAVE_MEMBLOCK
1945	---help---
1946	  This option adds a kernel parameter 'memtest', which allows memtest
1947	  to be set.
1948	        memtest=0, mean disabled; -- default
1949	        memtest=1, mean do 1 test pattern;
1950	        ...
1951	        memtest=17, mean do 17 test patterns.
1952	  If you are unsure how to answer this question, answer N.
1953
1954config TEST_STATIC_KEYS
1955	tristate "Test static keys"
 
 
1956	default n
1957	depends on m
1958	help
1959	  Test the static key interfaces.
1960
1961	  If unsure, say N.
 
 
 
 
 
 
 
 
 
 
 
 
 
1962
1963config BUG_ON_DATA_CORRUPTION
1964	bool "Trigger a BUG when data corruption is detected"
1965	select DEBUG_LIST
1966	help
1967	  Select this option if the kernel should BUG when it encounters
1968	  data corruption in kernel memory structures when they get checked
1969	  for validity.
1970
1971	  If unsure, say N.
1972
1973source "samples/Kconfig"
 
 
 
 
 
1974
1975source "lib/Kconfig.kgdb"
 
 
1976
1977source "lib/Kconfig.ubsan"
1978
1979config ARCH_HAS_DEVMEM_IS_ALLOWED
1980	bool
1981
1982config STRICT_DEVMEM
1983	bool "Filter access to /dev/mem"
1984	depends on MMU && DEVMEM
1985	depends on ARCH_HAS_DEVMEM_IS_ALLOWED
1986	default y if TILE || PPC
1987	---help---
1988	  If this option is disabled, you allow userspace (root) access to all
1989	  of memory, including kernel and userspace memory. Accidental
1990	  access to this is obviously disastrous, but specific access can
1991	  be used by people debugging the kernel. Note that with PAT support
1992	  enabled, even in this case there are restrictions on /dev/mem
1993	  use due to the cache aliasing requirements.
1994
1995	  If this option is switched on, and IO_STRICT_DEVMEM=n, the /dev/mem
1996	  file only allows userspace access to PCI space and the BIOS code and
1997	  data regions.  This is sufficient for dosemu and X and all common
1998	  users of /dev/mem.
1999
2000	  If in doubt, say Y.
 
 
 
2001
2002config IO_STRICT_DEVMEM
2003	bool "Filter I/O access to /dev/mem"
2004	depends on STRICT_DEVMEM
2005	---help---
2006	  If this option is disabled, you allow userspace (root) access to all
2007	  io-memory regardless of whether a driver is actively using that
2008	  range.  Accidental access to this is obviously disastrous, but
2009	  specific access can be used by people debugging kernel drivers.
2010
2011	  If this option is switched on, the /dev/mem file only allows
2012	  userspace access to *idle* io-memory ranges (see /proc/iomem) This
2013	  may break traditional users of /dev/mem (dosemu, legacy X, etc...)
2014	  if the driver using a given range cannot be disabled.
 
 
 
2015
2016	  If in doubt, say Y.