lib/Kconfig.debug

   1
   2 config TIZEN_KERNEL_ENG
   3         bool "Enable TIZEN engineering kernel binary options"
   4         help
   5           Say 'Y' to turn on any engineering features as related to
   6           support Tizen engineering kernel binary.
   7           If you want the USR kernel binary version, say N.
   8
   9 config PRINTK_TIME
  10         bool "Show timing information on printks"
  11         depends on PRINTK
  12         help
  13           Selecting this option causes time stamps of the printk()
  14           messages to be added to the output of the syslog() system
  15           call and at the console.
  16
  17           The timestamp is always recorded internally, and exported
  18           to /dev/kmsg. This flag just specifies if the timestamp should
  19           be included, not that the timestamp is recorded.
  20
  21           The behavior is also controlled by the kernel command line
  22           parameter printk.time=1. See Documentation/kernel-parameters.txt
  23
  24 config PRINTK_PROCESS
  25         bool "Show process information on printks"
  26         depends on PRINTK
  27         help
  28           Selecting this option causes process name and PID to be
  29           included in printk output. Or add printk.process=1 at boot-time.
  30
  31 config DEFAULT_MESSAGE_LOGLEVEL
  32         int "Default message log level (1-7)"
  33         range 1 7
  34         default "4"
  35         help
  36           Default log level for printk statements with no specified priority.
  37
  38           This was hard-coded to KERN_WARNING since at least 2.6.10 but folks
  39           that are auditing their logs closely may want to set it to a lower
  40           priority.
  41
  42 config ENABLE_WARN_DEPRECATED
  43         bool "Enable __deprecated logic"
  44         default y
  45         help
  46           Enable the __deprecated logic in the kernel build.
  47           Disable this to suppress the "warning: 'foo' is deprecated
  48           (declared at kernel/power/somefile.c:1234)" messages.
  49
  50 config ENABLE_MUST_CHECK
  51         bool "Enable __must_check logic"
  52         default y
  53         help
  54           Enable the __must_check logic in the kernel build.  Disable this to
  55           suppress the "warning: ignoring return value of 'foo', declared with
  56           attribute warn_unused_result" messages.
  57
  58 config FRAME_WARN
  59         int "Warn for stack frames larger than (needs gcc 4.4)"
  60         range 0 8192
  61         default 1024 if !64BIT
  62         default 2048 if 64BIT
  63         help
  64           Tell gcc to warn at build time for stack frames larger than this.
  65           Setting this too low will cause a lot of warnings.
  66           Setting it to 0 disables the warning.
  67           Requires gcc 4.4
  68
  69 config MAGIC_SYSRQ
  70         bool "Magic SysRq key"
  71         depends on !UML
  72         help
  73           If you say Y here, you will have some control over the system even
  74           if the system crashes for example during kernel debugging (e.g., you
  75           will be able to flush the buffer cache to disk, reboot the system
  76           immediately or dump some status information). This is accomplished
  77           by pressing various keys while holding SysRq (Alt+PrintScreen). It
  78           also works on a serial console (on PC hardware at least), if you
  79           send a BREAK and then within 5 seconds a command keypress. The
  80           keys are documented in <file:Documentation/sysrq.txt>. Don't say Y
  81           unless you really know what this hack does.
  82
  83 config STRIP_ASM_SYMS
  84         bool "Strip assembler-generated symbols during link"
  85         default n
  86         help
  87           Strip internal assembler-generated symbols during a link (symbols
  88           that look like '.Lxxx') so they don't pollute the output of
  89           get_wchan() and suchlike.
  90
  91 config READABLE_ASM
  92         bool "Generate readable assembler code"
  93         depends on DEBUG_KERNEL
  94         help
  95           Disable some compiler optimizations that tend to generate human unreadable
  96           assembler output. This may make the kernel slightly slower, but it helps
  97           to keep kernel developers who have to stare a lot at assembler listings
  98           sane.
  99
 100 config UNUSED_SYMBOLS
 101         bool "Enable unused/obsolete exported symbols"
 102         default y if X86
 103         help
 104           Unused but exported symbols make the kernel needlessly bigger.  For
 105           that reason most of these unused exports will soon be removed.  This
 106           option is provided temporarily to provide a transition period in case
 107           some external kernel module needs one of these symbols anyway. If you
 108           encounter such a case in your module, consider if you are actually
 109           using the right API.  (rationale: since nobody in the kernel is using
 110           this in a module, there is a pretty good chance it's actually the
 111           wrong interface to use).  If you really need the symbol, please send a
 112           mail to the linux kernel mailing list mentioning the symbol and why
 113           you really need it, and what the merge plan to the mainline kernel for
 114           your module is.
 115
 116 config DEBUG_FS
 117         bool "Debug Filesystem"
 118         help
 119           debugfs is a virtual file system that kernel developers use to put
 120           debugging files into.  Enable this option to be able to read and
 121           write to these files.
 122
 123           For detailed documentation on the debugfs API, see
 124           Documentation/DocBook/filesystems.
 125
 126           If unsure, say N.
 127
 128 config HEADERS_CHECK
 129         bool "Run 'make headers_check' when building vmlinux"
 130         depends on !UML
 131         help
 132           This option will extract the user-visible kernel headers whenever
 133           building the kernel, and will run basic sanity checks on them to
 134           ensure that exported files do not attempt to include files which
 135           were not exported, etc.
 136
 137           If you're making modifications to header files which are
 138           relevant for userspace, say 'Y', and check the headers
 139           exported to $(INSTALL_HDR_PATH) (usually 'usr/include' in
 140           your build tree), to make sure they're suitable.
 141
 142 config DEBUG_SECTION_MISMATCH
 143         bool "Enable full Section mismatch analysis"
 144         help
 145           The section mismatch analysis checks if there are illegal
 146           references from one section to another section.
 147           During linktime or runtime, some sections are dropped;
 148           any use of code/data previously in these sections would
 149           most likely result in an oops.
 150           In the code, functions and variables are annotated with
 151           __init, __cpuinit, etc. (see the full list in include/linux/init.h),
 152           which results in the code/data being placed in specific sections.
 153           The section mismatch analysis is always performed after a full
 154           kernel build, and enabling this option causes the following
 155           additional steps to occur:
 156           - Add the option -fno-inline-functions-called-once to gcc commands.
 157             When inlining a function annotated with __init in a non-init
 158             function, we would lose the section information and thus
 159             the analysis would not catch the illegal reference.
 160             This option tells gcc to inline less (but it does result in
 161             a larger kernel).
 162           - Run the section mismatch analysis for each module/built-in.o file.
 163             When we run the section mismatch analysis on vmlinux.o, we
 164             lose valueble information about where the mismatch was
 165             introduced.
 166             Running the analysis for each module/built-in.o file
 167             tells where the mismatch happens much closer to the
 168             source. The drawback is that the same mismatch is
 169             reported at least twice.
 170           - Enable verbose reporting from modpost in order to help resolve
 171             the section mismatches that are reported.
 172
 173 config DEBUG_KERNEL
 174         bool "Kernel debugging"
 175         help
 176           Say Y here if you are developing drivers or trying to debug and
 177           identify kernel problems.
 178
 179 config DEBUG_SHIRQ
 180         bool "Debug shared IRQ handlers"
 181         depends on DEBUG_KERNEL && GENERIC_HARDIRQS
 182         help
 183           Enable this to generate a spurious interrupt as soon as a shared
 184           interrupt handler is registered, and just before one is deregistered.
 185           Drivers ought to be able to handle interrupts coming in at those
 186           points; some don't and need to be caught.
 187
 188 config LOCKUP_DETECTOR
 189         bool "Detect Hard and Soft Lockups"
 190         depends on DEBUG_KERNEL && !S390
 191         help
 192           Say Y here to enable the kernel to act as a watchdog to detect
 193           hard and soft lockups.
 194
 195           Softlockups are bugs that cause the kernel to loop in kernel
 196           mode for more than 20 seconds, without giving other tasks a
 197           chance to run.  The current stack trace is displayed upon
 198           detection and the system will stay locked up.
 199
 200           Hardlockups are bugs that cause the CPU to loop in kernel mode
 201           for more than 10 seconds, without letting other interrupts have a
 202           chance to run.  The current stack trace is displayed upon detection
 203           and the system will stay locked up.
 204
 205           The overhead should be minimal.  A periodic hrtimer runs to
 206           generate interrupts and kick the watchdog task every 4 seconds.
 207           An NMI is generated every 10 seconds or so to check for hardlockups.
 208           If NMIs are not available on the platform, every 12 seconds the
 209           hrtimer interrupt on one cpu will be used to check for hardlockups
 210           on the next cpu.
 211
 212           The frequency of hrtimer and NMI events and the soft and hard lockup
 213           thresholds can be controlled through the sysctl watchdog_thresh.
 214
 215 config HARDLOCKUP_DETECTOR_NMI
 216         def_bool y
 217         depends on LOCKUP_DETECTOR && !HAVE_NMI_WATCHDOG
 218         depends on PERF_EVENTS && HAVE_PERF_EVENTS_NMI
 219
 220 config HARDLOCKUP_DETECTOR_OTHER_CPU
 221         def_bool y
 222         depends on LOCKUP_DETECTOR && SMP
 223         depends on !HARDLOCKUP_DETECTOR_NMI && !HAVE_NMI_WATCHDOG
 224
 225 config HARDLOCKUP_DETECTOR
 226         def_bool y
 227         depends on HARDLOCKUP_DETECTOR_NMI || HARDLOCKUP_DETECTOR_OTHER_CPU
 228
 229 config BOOTPARAM_HARDLOCKUP_PANIC
 230         bool "Panic (Reboot) On Hard Lockups"
 231         depends on HARDLOCKUP_DETECTOR
 232         help
 233           Say Y here to enable the kernel to panic on "hard lockups",
 234           which are bugs that cause the kernel to loop in kernel
 235           mode with interrupts disabled for more than 10 seconds (configurable
 236           using the watchdog_thresh sysctl).
 237
 238           Say N if unsure.
 239
 240 config BOOTPARAM_HARDLOCKUP_PANIC_VALUE
 241         int
 242         depends on HARDLOCKUP_DETECTOR
 243         range 0 1
 244         default 0 if !BOOTPARAM_HARDLOCKUP_PANIC
 245         default 1 if BOOTPARAM_HARDLOCKUP_PANIC
 246
 247 config BOOTPARAM_SOFTLOCKUP_PANIC
 248         bool "Panic (Reboot) On Soft Lockups"
 249         depends on LOCKUP_DETECTOR
 250         help
 251           Say Y here to enable the kernel to panic on "soft lockups",
 252           which are bugs that cause the kernel to loop in kernel
 253           mode for more than 20 seconds (configurable using the watchdog_thresh
 254           sysctl), without giving other tasks a chance to run.
 255
 256           The panic can be used in combination with panic_timeout,
 257           to cause the system to reboot automatically after a
 258           lockup has been detected. This feature is useful for
 259           high-availability systems that have uptime guarantees and
 260           where a lockup must be resolved ASAP.
 261
 262           Say N if unsure.
 263
 264 config BOOTPARAM_SOFTLOCKUP_PANIC_VALUE
 265         int
 266         depends on LOCKUP_DETECTOR
 267         range 0 1
 268         default 0 if !BOOTPARAM_SOFTLOCKUP_PANIC
 269         default 1 if BOOTPARAM_SOFTLOCKUP_PANIC
 270
 271 config PANIC_ON_OOPS
 272         bool "Panic on Oops"
 273         help
 274           Say Y here to enable the kernel to panic when it oopses. This
 275           has the same effect as setting oops=panic on the kernel command
 276           line.
 277
 278           This feature is useful to ensure that the kernel does not do
 279           anything erroneous after an oops which could result in data
 280           corruption or other issues.
 281
 282           Say N if unsure.
 283
 284 config PANIC_ON_OOPS_VALUE
 285         int
 286         range 0 1
 287         default 0 if !PANIC_ON_OOPS
 288         default 1 if PANIC_ON_OOPS
 289
 290 config DETECT_HUNG_TASK
 291         bool "Detect Hung Tasks"
 292         depends on DEBUG_KERNEL
 293         default LOCKUP_DETECTOR
 294         help
 295           Say Y here to enable the kernel to detect "hung tasks",
 296           which are bugs that cause the task to be stuck in
 297           uninterruptible "D" state indefinitiley.
 298
 299           When a hung task is detected, the kernel will print the
 300           current stack trace (which you should report), but the
 301           task will stay in uninterruptible state. If lockdep is
 302           enabled then all held locks will also be reported. This
 303           feature has negligible overhead.
 304
 305 config DEFAULT_HUNG_TASK_TIMEOUT
 306         int "Default timeout for hung task detection (in seconds)"
 307         depends on DETECT_HUNG_TASK
 308         default 120
 309         help
 310           This option controls the default timeout (in seconds) used
 311           to determine when a task has become non-responsive and should
 312           be considered hung.
 313
 314           It can be adjusted at runtime via the kernel.hung_task_timeout_secs
 315           sysctl or by writing a value to
 316           /proc/sys/kernel/hung_task_timeout_secs.
 317
 318           A timeout of 0 disables the check.  The default is two minutes.
 319           Keeping the default should be fine in most cases.
 320
 321 config BOOTPARAM_HUNG_TASK_PANIC
 322         bool "Panic (Reboot) On Hung Tasks"
 323         depends on DETECT_HUNG_TASK
 324         help
 325           Say Y here to enable the kernel to panic on "hung tasks",
 326           which are bugs that cause the kernel to leave a task stuck
 327           in uninterruptible "D" state.
 328
 329           The panic can be used in combination with panic_timeout,
 330           to cause the system to reboot automatically after a
 331           hung task has been detected. This feature is useful for
 332           high-availability systems that have uptime guarantees and
 333           where a hung tasks must be resolved ASAP.
 334
 335           Say N if unsure.
 336
 337 config BOOTPARAM_HUNG_TASK_PANIC_VALUE
 338         int
 339         depends on DETECT_HUNG_TASK
 340         range 0 1
 341         default 0 if !BOOTPARAM_HUNG_TASK_PANIC
 342         default 1 if BOOTPARAM_HUNG_TASK_PANIC
 343
 344 config SCHED_DEBUG
 345         bool "Collect scheduler debugging info"
 346         depends on DEBUG_KERNEL && PROC_FS
 347         default y
 348         help
 349           If you say Y here, the /proc/sched_debug file will be provided
 350           that can help debug the scheduler. The runtime overhead of this
 351           option is minimal.
 352
 353 config SCHEDSTATS
 354         bool "Collect scheduler statistics"
 355         depends on DEBUG_KERNEL && PROC_FS
 356         help
 357           If you say Y here, additional code will be inserted into the
 358           scheduler and related routines to collect statistics about
 359           scheduler behavior and provide them in /proc/schedstat.  These
 360           stats may be useful for both tuning and debugging the scheduler
 361           If you aren't debugging the scheduler or trying to tune a specific
 362           application, you can say N to avoid the very slight overhead
 363           this adds.
 364
 365 config TIMER_STATS
 366         bool "Collect kernel timers statistics"
 367         depends on DEBUG_KERNEL && PROC_FS
 368         help
 369           If you say Y here, additional code will be inserted into the
 370           timer routines to collect statistics about kernel timers being
 371           reprogrammed. The statistics can be read from /proc/timer_stats.
 372           The statistics collection is started by writing 1 to /proc/timer_stats,
 373           writing 0 stops it. This feature is useful to collect information
 374           about timer usage patterns in kernel and userspace. This feature
 375           is lightweight if enabled in the kernel config but not activated
 376           (it defaults to deactivated on bootup and will only be activated
 377           if some application like powertop activates it explicitly).
 378
 379 config DEBUG_OBJECTS
 380         bool "Debug object operations"
 381         depends on DEBUG_KERNEL
 382         help
 383           If you say Y here, additional code will be inserted into the
 384           kernel to track the life time of various objects and validate
 385           the operations on those objects.
 386
 387 config DEBUG_OBJECTS_SELFTEST
 388         bool "Debug objects selftest"
 389         depends on DEBUG_OBJECTS
 390         help
 391           This enables the selftest of the object debug code.
 392
 393 config DEBUG_OBJECTS_FREE
 394         bool "Debug objects in freed memory"
 395         depends on DEBUG_OBJECTS
 396         help
 397           This enables checks whether a k/v free operation frees an area
 398           which contains an object which has not been deactivated
 399           properly. This can make kmalloc/kfree-intensive workloads
 400           much slower.
 401
 402 config DEBUG_OBJECTS_TIMERS
 403         bool "Debug timer objects"
 404         depends on DEBUG_OBJECTS
 405         help
 406           If you say Y here, additional code will be inserted into the
 407           timer routines to track the life time of timer objects and
 408           validate the timer operations.
 409
 410 config DEBUG_OBJECTS_WORK
 411         bool "Debug work objects"
 412         depends on DEBUG_OBJECTS
 413         help
 414           If you say Y here, additional code will be inserted into the
 415           work queue routines to track the life time of work objects and
 416           validate the work operations.
 417
 418 config DEBUG_OBJECTS_RCU_HEAD
 419         bool "Debug RCU callbacks objects"
 420         depends on DEBUG_OBJECTS
 421         help
 422           Enable this to turn on debugging of RCU list heads (call_rcu() usage).
 423
 424 config DEBUG_OBJECTS_PERCPU_COUNTER
 425         bool "Debug percpu counter objects"
 426         depends on DEBUG_OBJECTS
 427         help
 428           If you say Y here, additional code will be inserted into the
 429           percpu counter routines to track the life time of percpu counter
 430           objects and validate the percpu counter operations.
 431
 432 config DEBUG_OBJECTS_ENABLE_DEFAULT
 433         int "debug_objects bootup default value (0-1)"
 434         range 0 1
 435         default "1"
 436         depends on DEBUG_OBJECTS
 437         help
 438           Debug objects boot parameter default value
 439
 440 config DEBUG_SLAB
 441         bool "Debug slab memory allocations"
 442         depends on DEBUG_KERNEL && SLAB && !KMEMCHECK
 443         help
 444           Say Y here to have the kernel do limited verification on memory
 445           allocation as well as poisoning memory on free to catch use of freed
 446           memory. This can make kmalloc/kfree-intensive workloads much slower.
 447
 448 config DEBUG_SLAB_LEAK
 449         bool "Memory leak debugging"
 450         depends on DEBUG_SLAB
 451
 452 config SLUB_DEBUG_ON
 453         bool "SLUB debugging on by default"
 454         depends on SLUB && SLUB_DEBUG && !KMEMCHECK
 455         default n
 456         help
 457           Boot with debugging on by default. SLUB boots by default with
 458           the runtime debug capabilities switched off. Enabling this is
 459           equivalent to specifying the "slub_debug" parameter on boot.
 460           There is no support for more fine grained debug control like
 461           possible with slub_debug=xxx. SLUB debugging may be switched
 462           off in a kernel built with CONFIG_SLUB_DEBUG_ON by specifying
 463           "slub_debug=-".
 464
 465 config SLUB_STATS
 466         default n
 467         bool "Enable SLUB performance statistics"
 468         depends on SLUB && SYSFS
 469         help
 470           SLUB statistics are useful to debug SLUBs allocation behavior in
 471           order find ways to optimize the allocator. This should never be
 472           enabled for production use since keeping statistics slows down
 473           the allocator by a few percentage points. The slabinfo command
 474           supports the determination of the most active slabs to figure
 475           out which slabs are relevant to a particular load.
 476           Try running: slabinfo -DA
 477
 478 config HAVE_DEBUG_KMEMLEAK
 479         bool
 480
 481 config DEBUG_KMEMLEAK
 482         bool "Kernel memory leak detector"
 483         depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK
 484         select DEBUG_FS
 485         select STACKTRACE if STACKTRACE_SUPPORT
 486         select KALLSYMS
 487         select CRC32
 488         help
 489           Say Y here if you want to enable the memory leak
 490           detector. The memory allocation/freeing is traced in a way
 491           similar to the Boehm's conservative garbage collector, the
 492           difference being that the orphan objects are not freed but
 493           only shown in /sys/kernel/debug/kmemleak. Enabling this
 494           feature will introduce an overhead to memory
 495           allocations. See Documentation/kmemleak.txt for more
 496           details.
 497
 498           Enabling DEBUG_SLAB or SLUB_DEBUG may increase the chances
 499           of finding leaks due to the slab objects poisoning.
 500
 501           In order to access the kmemleak file, debugfs needs to be
 502           mounted (usually at /sys/kernel/debug).
 503
 504 config DEBUG_KMEMLEAK_EARLY_LOG_SIZE
 505         int "Maximum kmemleak early log entries"
 506         depends on DEBUG_KMEMLEAK
 507         range 200 40000
 508         default 400
 509         help
 510           Kmemleak must track all the memory allocations to avoid
 511           reporting false positives. Since memory may be allocated or
 512           freed before kmemleak is initialised, an early log buffer is
 513           used to store these actions. If kmemleak reports "early log
 514           buffer exceeded", please increase this value.
 515
 516 config DEBUG_KMEMLEAK_TEST
 517         tristate "Simple test for the kernel memory leak detector"
 518         depends on DEBUG_KMEMLEAK && m
 519         help
 520           This option enables a module that explicitly leaks memory.
 521
 522           If unsure, say N.
 523
 524 config DEBUG_KMEMLEAK_DEFAULT_OFF
 525         bool "Default kmemleak to off"
 526         depends on DEBUG_KMEMLEAK
 527         help
 528           Say Y here to disable kmemleak by default. It can then be enabled
 529           on the command line via kmemleak=on.
 530
 531 config DEBUG_PREEMPT
 532         bool "Debug preemptible kernel"
 533         depends on DEBUG_KERNEL && PREEMPT && TRACE_IRQFLAGS_SUPPORT
 534         default y
 535         help
 536           If you say Y here then the kernel will use a debug variant of the
 537           commonly used smp_processor_id() function and will print warnings
 538           if kernel code uses it in a preemption-unsafe way. Also, the kernel
 539           will detect preemption count underflows.
 540
 541 config DEBUG_RT_MUTEXES
 542         bool "RT Mutex debugging, deadlock detection"
 543         depends on DEBUG_KERNEL && RT_MUTEXES
 544         help
 545          This allows rt mutex semantics violations and rt mutex related
 546          deadlocks (lockups) to be detected and reported automatically.
 547
 548 config DEBUG_PI_LIST
 549         bool
 550         default y
 551         depends on DEBUG_RT_MUTEXES
 552
 553 config RT_MUTEX_TESTER
 554         bool "Built-in scriptable tester for rt-mutexes"
 555         depends on DEBUG_KERNEL && RT_MUTEXES
 556         help
 557           This option enables a rt-mutex tester.
 558
 559 config DEBUG_SPINLOCK
 560         bool "Spinlock and rw-lock debugging: basic checks"
 561         depends on DEBUG_KERNEL
 562         select UNINLINE_SPIN_UNLOCK
 563         help
 564           Say Y here and build SMP to catch missing spinlock initialization
 565           and certain other kinds of spinlock errors commonly made.  This is
 566           best used in conjunction with the NMI watchdog so that spinlock
 567           deadlocks are also debuggable.
 568
 569 config DEBUG_MUTEXES
 570         bool "Mutex debugging: basic checks"
 571         depends on DEBUG_KERNEL
 572         help
 573          This feature allows mutex semantics violations to be detected and
 574          reported.
 575
 576 config DEBUG_LOCK_ALLOC
 577         bool "Lock debugging: detect incorrect freeing of live locks"
 578         depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
 579         select DEBUG_SPINLOCK
 580         select DEBUG_MUTEXES
 581         select LOCKDEP
 582         help
 583          This feature will check whether any held lock (spinlock, rwlock,
 584          mutex or rwsem) is incorrectly freed by the kernel, via any of the
 585          memory-freeing routines (kfree(), kmem_cache_free(), free_pages(),
 586          vfree(), etc.), whether a live lock is incorrectly reinitialized via
 587          spin_lock_init()/mutex_init()/etc., or whether there is any lock
 588          held during task exit.
 589
 590 config PROVE_LOCKING
 591         bool "Lock debugging: prove locking correctness"
 592         depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
 593         select LOCKDEP
 594         select DEBUG_SPINLOCK
 595         select DEBUG_MUTEXES
 596         select DEBUG_LOCK_ALLOC
 597         select TRACE_IRQFLAGS
 598         default n
 599         help
 600          This feature enables the kernel to prove that all locking
 601          that occurs in the kernel runtime is mathematically
 602          correct: that under no circumstance could an arbitrary (and
 603          not yet triggered) combination of observed locking
 604          sequences (on an arbitrary number of CPUs, running an
 605          arbitrary number of tasks and interrupt contexts) cause a
 606          deadlock.
 607
 608          In short, this feature enables the kernel to report locking
 609          related deadlocks before they actually occur.
 610
 611          The proof does not depend on how hard and complex a
 612          deadlock scenario would be to trigger: how many
 613          participant CPUs, tasks and irq-contexts would be needed
 614          for it to trigger. The proof also does not depend on
 615          timing: if a race and a resulting deadlock is possible
 616          theoretically (no matter how unlikely the race scenario
 617          is), it will be proven so and will immediately be
 618          reported by the kernel (once the event is observed that
 619          makes the deadlock theoretically possible).
 620
 621          If a deadlock is impossible (i.e. the locking rules, as
 622          observed by the kernel, are mathematically correct), the
 623          kernel reports nothing.
 624
 625          NOTE: this feature can also be enabled for rwlocks, mutexes
 626          and rwsems - in which case all dependencies between these
 627          different locking variants are observed and mapped too, and
 628          the proof of observed correctness is also maintained for an
 629          arbitrary combination of these separate locking variants.
 630
 631          For more details, see Documentation/lockdep-design.txt.
 632
 633 config LOCKDEP
 634         bool
 635         depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
 636         select STACKTRACE
 637         select FRAME_POINTER if !MIPS && !PPC && !ARM_UNWIND && !S390 && !MICROBLAZE
 638         select KALLSYMS
 639         select KALLSYMS_ALL
 640
 641 config LOCK_STAT
 642         bool "Lock usage statistics"
 643         depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
 644         select LOCKDEP
 645         select DEBUG_SPINLOCK
 646         select DEBUG_MUTEXES
 647         select DEBUG_LOCK_ALLOC
 648         default n
 649         help
 650          This feature enables tracking lock contention points
 651
 652          For more details, see Documentation/lockstat.txt
 653
 654          This also enables lock events required by "perf lock",
 655          subcommand of perf.
 656          If you want to use "perf lock", you also need to turn on
 657          CONFIG_EVENT_TRACING.
 658
 659          CONFIG_LOCK_STAT defines "contended" and "acquired" lock events.
 660          (CONFIG_LOCKDEP defines "acquire" and "release" events.)
 661
 662 config DEBUG_LOCKDEP
 663         bool "Lock dependency engine debugging"
 664         depends on DEBUG_KERNEL && LOCKDEP
 665         help
 666           If you say Y here, the lock dependency engine will do
 667           additional runtime checks to debug itself, at the price
 668           of more runtime overhead.
 669
 670 config TRACE_IRQFLAGS
 671         bool
 672         help
 673           Enables hooks to interrupt enabling and disabling for
 674           either tracing or lock debugging.
 675
 676 config DEBUG_ATOMIC_SLEEP
 677         bool "Sleep inside atomic section checking"
 678         select PREEMPT_COUNT
 679         depends on DEBUG_KERNEL
 680         help
 681           If you say Y here, various routines which may sleep will become very
 682           noisy if they are called inside atomic sections: when a spinlock is
 683           held, inside an rcu read side critical section, inside preempt disabled
 684           sections, inside an interrupt, etc...
 685
 686 config DEBUG_LOCKING_API_SELFTESTS
 687         bool "Locking API boot-time self-tests"
 688         depends on DEBUG_KERNEL
 689         help
 690           Say Y here if you want the kernel to run a short self-test during
 691           bootup. The self-test checks whether common types of locking bugs
 692           are detected by debugging mechanisms or not. (if you disable
 693           lock debugging then those bugs wont be detected of course.)
 694           The following locking APIs are covered: spinlocks, rwlocks,
 695           mutexes and rwsems.
 696
 697 config STACKTRACE
 698         bool "Stacktrace"
 699         depends on STACKTRACE_SUPPORT
 700         default y
 701
 702 config DEBUG_STACK_USAGE
 703         bool "Stack utilization instrumentation"
 704         depends on DEBUG_KERNEL && !IA64 && !PARISC && !METAG
 705         help
 706           Enables the display of the minimum amount of free stack which each
 707           task has ever had available in the sysrq-T and sysrq-P debug output.
 708
 709           This option will slow down process creation somewhat.
 710
 711 config DEBUG_KOBJECT
 712         bool "kobject debugging"
 713         depends on DEBUG_KERNEL
 714         help
 715           If you say Y here, some extra kobject debugging messages will be sent
 716           to the syslog.
 717
 718 config DEBUG_HIGHMEM
 719         bool "Highmem debugging"
 720         depends on DEBUG_KERNEL && HIGHMEM
 721         help
 722           This options enables addition error checking for high memory systems.
 723           Disable for production systems.
 724
 725 config HAVE_DEBUG_BUGVERBOSE
 726         bool
 727
 728 config DEBUG_BUGVERBOSE
 729         bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
 730         depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
 731         default y
 732         help
 733           Say Y here to make BUG() panics output the file name and line number
 734           of the BUG call as well as the EIP and oops trace.  This aids
 735           debugging but costs about 70-100K of memory.
 736
 737 config DEBUG_INFO
 738         bool "Compile the kernel with debug info"
 739         depends on DEBUG_KERNEL
 740         help
 741           If you say Y here the resulting kernel image will include
 742           debugging info resulting in a larger kernel image.
 743           This adds debug symbols to the kernel and modules (gcc -g), and
 744           is needed if you intend to use kernel crashdump or binary object
 745           tools like crash, kgdb, LKCD, gdb, etc on the kernel.
 746           Say Y here only if you plan to debug the kernel.
 747
 748           If unsure, say N.
 749
 750 config DEBUG_INFO_REDUCED
 751         bool "Reduce debugging information"
 752         depends on DEBUG_INFO
 753         help
 754           If you say Y here gcc is instructed to generate less debugging
 755           information for structure types. This means that tools that
 756           need full debugging information (like kgdb or systemtap) won't
 757           be happy. But if you merely need debugging information to
 758           resolve line numbers there is no loss. Advantage is that
 759           build directory object sizes shrink dramatically over a full
 760           DEBUG_INFO build and compile times are reduced too.
 761           Only works with newer gcc versions.
 762
 763 config DEBUG_VM
 764         bool "Debug VM"
 765         depends on DEBUG_KERNEL
 766         help
 767           Enable this to turn on extended checks in the virtual-memory system
 768           that may impact performance.
 769
 770           If unsure, say N.
 771
 772 config DEBUG_VM_RB
 773         bool "Debug VM red-black trees"
 774         depends on DEBUG_VM
 775         help
 776           Enable this to turn on more extended checks in the virtual-memory
 777           system that may impact performance.
 778
 779           If unsure, say N.
 780
 781 config DEBUG_VIRTUAL
 782         bool "Debug VM translations"
 783         depends on DEBUG_KERNEL && X86
 784         help
 785           Enable some costly sanity checks in virtual to page code. This can
 786           catch mistakes with virt_to_page() and friends.
 787
 788           If unsure, say N.
 789
 790 config DEBUG_NOMMU_REGIONS
 791         bool "Debug the global anon/private NOMMU mapping region tree"
 792         depends on DEBUG_KERNEL && !MMU
 793         help
 794           This option causes the global tree of anonymous and private mapping
 795           regions to be regularly checked for invalid topology.
 796
 797 config DEBUG_WRITECOUNT
 798         bool "Debug filesystem writers count"
 799         depends on DEBUG_KERNEL
 800         help
 801           Enable this to catch wrong use of the writers count in struct
 802           vfsmount.  This will increase the size of each file struct by
 803           32 bits.
 804
 805           If unsure, say N.
 806
 807 config DEBUG_MEMORY_INIT
 808         bool "Debug memory initialisation" if EXPERT
 809         default !EXPERT
 810         help
 811           Enable this for additional checks during memory initialisation.
 812           The sanity checks verify aspects of the VM such as the memory model
 813           and other information provided by the architecture. Verbose
 814           information will be printed at KERN_DEBUG loglevel depending
 815           on the mminit_loglevel= command-line option.
 816
 817           If unsure, say Y
 818
 819 config DEBUG_LIST
 820         bool "Debug linked list manipulation"
 821         depends on DEBUG_KERNEL
 822         help
 823           Enable this to turn on extended checks in the linked-list
 824           walking routines.
 825
 826           If unsure, say N.
 827
 828 config TEST_LIST_SORT
 829         bool "Linked list sorting test"
 830         depends on DEBUG_KERNEL
 831         help
 832           Enable this to turn on 'list_sort()' function test. This test is
 833           executed only once during system boot, so affects only boot time.
 834
 835           If unsure, say N.
 836
 837 config DEBUG_SG
 838         bool "Debug SG table operations"
 839         depends on DEBUG_KERNEL
 840         help
 841           Enable this to turn on checks on scatter-gather tables. This can
 842           help find problems with drivers that do not properly initialize
 843           their sg tables.
 844
 845           If unsure, say N.
 846
 847 config DEBUG_NOTIFIERS
 848         bool "Debug notifier call chains"
 849         depends on DEBUG_KERNEL
 850         help
 851           Enable this to turn on sanity checking for notifier call chains.
 852           This is most useful for kernel developers to make sure that
 853           modules properly unregister themselves from notifier chains.
 854           This is a relatively cheap check but if you care about maximum
 855           performance, say N.
 856
 857 config DEBUG_CREDENTIALS
 858         bool "Debug credential management"
 859         depends on DEBUG_KERNEL
 860         help
 861           Enable this to turn on some debug checking for credential
 862           management.  The additional code keeps track of the number of
 863           pointers from task_structs to any given cred struct, and checks to
 864           see that this number never exceeds the usage count of the cred
 865           struct.
 866
 867           Furthermore, if SELinux is enabled, this also checks that the
 868           security pointer in the cred struct is never seen to be invalid.
 869
 870           If unsure, say N.
 871
 872 #
 873 # Select this config option from the architecture Kconfig, if it
 874 # is preferred to always offer frame pointers as a config
 875 # option on the architecture (regardless of KERNEL_DEBUG):
 876 #
 877 config ARCH_WANT_FRAME_POINTERS
 878         bool
 879         help
 880
 881 config FRAME_POINTER
 882         bool "Compile the kernel with frame pointers"
 883         depends on DEBUG_KERNEL && \
 884                 (CRIS || M68K || FRV || UML || \
 885                  AVR32 || SUPERH || BLACKFIN || MN10300 || METAG) || \
 886                 ARCH_WANT_FRAME_POINTERS
 887         default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS
 888         help
 889           If you say Y here the resulting kernel image will be slightly
 890           larger and slower, but it gives very useful debugging information
 891           in case of kernel bugs. (precise oopses/stacktraces/warnings)
 892
 893 config BOOT_PRINTK_DELAY
 894         bool "Delay each boot printk message by N milliseconds"
 895         depends on DEBUG_KERNEL && PRINTK && GENERIC_CALIBRATE_DELAY
 896         help
 897           This build option allows you to read kernel boot messages
 898           by inserting a short delay after each one.  The delay is
 899           specified in milliseconds on the kernel command line,
 900           using "boot_delay=N".
 901
 902           It is likely that you would also need to use "lpj=M" to preset
 903           the "loops per jiffie" value.
 904           See a previous boot log for the "lpj" value to use for your
 905           system, and then set "lpj=M" before setting "boot_delay=N".
 906           NOTE:  Using this option may adversely affect SMP systems.
 907           I.e., processors other than the first one may not boot up.
 908           BOOT_PRINTK_DELAY also may cause LOCKUP_DETECTOR to detect
 909           what it believes to be lockup conditions.
 910
 911 menu "RCU Debugging"
 912
 913 config PROVE_RCU
 914         bool "RCU debugging: prove RCU correctness"
 915         depends on PROVE_LOCKING
 916         default n
 917         help
 918          This feature enables lockdep extensions that check for correct
 919          use of RCU APIs.  This is currently under development.  Say Y
 920          if you want to debug RCU usage or help work on the PROVE_RCU
 921          feature.
 922
 923          Say N if you are unsure.
 924
 925 config PROVE_RCU_REPEATEDLY
 926         bool "RCU debugging: don't disable PROVE_RCU on first splat"
 927         depends on PROVE_RCU
 928         default n
 929         help
 930          By itself, PROVE_RCU will disable checking upon issuing the
 931          first warning (or "splat").  This feature prevents such
 932          disabling, allowing multiple RCU-lockdep warnings to be printed
 933          on a single reboot.
 934
 935          Say Y to allow multiple RCU-lockdep warnings per boot.
 936
 937          Say N if you are unsure.
 938
 939 config PROVE_RCU_DELAY
 940         bool "RCU debugging: preemptible RCU race provocation"
 941         depends on DEBUG_KERNEL && PREEMPT_RCU
 942         default n
 943         help
 944          There is a class of races that involve an unlikely preemption
 945          of __rcu_read_unlock() just after ->rcu_read_lock_nesting has
 946          been set to INT_MIN.  This feature inserts a delay at that
 947          point to increase the probability of these races.
 948
 949          Say Y to increase probability of preemption of __rcu_read_unlock().
 950
 951          Say N if you are unsure.
 952
 953 config SPARSE_RCU_POINTER
 954         bool "RCU debugging: sparse-based checks for pointer usage"
 955         default n
 956         help
 957          This feature enables the __rcu sparse annotation for
 958          RCU-protected pointers.  This annotation will cause sparse
 959          to flag any non-RCU used of annotated pointers.  This can be
 960          helpful when debugging RCU usage.  Please note that this feature
 961          is not intended to enforce code cleanliness; it is instead merely
 962          a debugging aid.
 963
 964          Say Y to make sparse flag questionable use of RCU-protected pointers
 965
 966          Say N if you are unsure.
 967
 968 config RCU_TORTURE_TEST
 969         tristate "torture tests for RCU"
 970         depends on DEBUG_KERNEL
 971         default n
 972         help
 973           This option provides a kernel module that runs torture tests
 974           on the RCU infrastructure.  The kernel module may be built
 975           after the fact on the running kernel to be tested, if desired.
 976
 977           Say Y here if you want RCU torture tests to be built into
 978           the kernel.
 979           Say M if you want the RCU torture tests to build as a module.
 980           Say N if you are unsure.
 981
 982 config RCU_TORTURE_TEST_RUNNABLE
 983         bool "torture tests for RCU runnable by default"
 984         depends on RCU_TORTURE_TEST = y
 985         default n
 986         help
 987           This option provides a way to build the RCU torture tests
 988           directly into the kernel without them starting up at boot
 989           time.  You can use /proc/sys/kernel/rcutorture_runnable
 990           to manually override this setting.  This /proc file is
 991           available only when the RCU torture tests have been built
 992           into the kernel.
 993
 994           Say Y here if you want the RCU torture tests to start during
 995           boot (you probably don't).
 996           Say N here if you want the RCU torture tests to start only
 997           after being manually enabled via /proc.
 998
 999 config RCU_CPU_STALL_TIMEOUT
1000         int "RCU CPU stall timeout in seconds"
1001         depends on RCU_STALL_COMMON
1002         range 3 300
1003         default 21
1004         help
1005           If a given RCU grace period extends more than the specified
1006           number of seconds, a CPU stall warning is printed.  If the
1007           RCU grace period persists, additional CPU stall warnings are
1008           printed at more widely spaced intervals.
1009
1010 config RCU_CPU_STALL_VERBOSE
1011         bool "Print additional per-task information for RCU_CPU_STALL_DETECTOR"
1012         depends on TREE_PREEMPT_RCU
1013         default y
1014         help
1015           This option causes RCU to printk detailed per-task information
1016           for any tasks that are stalling the current RCU grace period.
1017
1018           Say N if you are unsure.
1019
1020           Say Y if you want to enable such checks.
1021
1022 config RCU_CPU_STALL_INFO
1023         bool "Print additional diagnostics on RCU CPU stall"
1024         depends on (TREE_RCU || TREE_PREEMPT_RCU) && DEBUG_KERNEL
1025         default n
1026         help
1027           For each stalled CPU that is aware of the current RCU grace
1028           period, print out additional per-CPU diagnostic information
1029           regarding scheduling-clock ticks, idle state, and,
1030           for RCU_FAST_NO_HZ kernels, idle-entry state.
1031
1032           Say N if you are unsure.
1033
1034           Say Y if you want to enable such diagnostics.
1035
1036 config RCU_TRACE
1037         bool "Enable tracing for RCU"
1038         depends on DEBUG_KERNEL
1039         select TRACE_CLOCK
1040         help
1041           This option provides tracing in RCU which presents stats
1042           in debugfs for debugging RCU implementation.
1043
1044           Say Y here if you want to enable RCU tracing
1045           Say N if you are unsure.
1046
1047 endmenu # "RCU Debugging"
1048
1049 config KPROBES_SANITY_TEST
1050         bool "Kprobes sanity tests"
1051         depends on DEBUG_KERNEL
1052         depends on KPROBES
1053         default n
1054         help
1055           This option provides for testing basic kprobes functionality on
1056           boot. A sample kprobe, jprobe and kretprobe are inserted and
1057           verified for functionality.
1058
1059           Say N if you are unsure.
1060
1061 config BACKTRACE_SELF_TEST
1062         tristate "Self test for the backtrace code"
1063         depends on DEBUG_KERNEL
1064         default n
1065         help
1066           This option provides a kernel module that can be used to test
1067           the kernel stack backtrace code. This option is not useful
1068           for distributions or general kernels, but only for kernel
1069           developers working on architecture code.
1070
1071           Note that if you want to also test saved backtraces, you will
1072           have to enable STACKTRACE as well.
1073
1074           Say N if you are unsure.
1075
1076 config DEBUG_BLOCK_EXT_DEVT
1077         bool "Force extended block device numbers and spread them"
1078         depends on DEBUG_KERNEL
1079         depends on BLOCK
1080         default n
1081         help
1082           BIG FAT WARNING: ENABLING THIS OPTION MIGHT BREAK BOOTING ON
1083           SOME DISTRIBUTIONS.  DO NOT ENABLE THIS UNLESS YOU KNOW WHAT
1084           YOU ARE DOING.  Distros, please enable this and fix whatever
1085           is broken.
1086
1087           Conventionally, block device numbers are allocated from
1088           predetermined contiguous area.  However, extended block area
1089           may introduce non-contiguous block device numbers.  This
1090           option forces most block device numbers to be allocated from
1091           the extended space and spreads them to discover kernel or
1092           userland code paths which assume predetermined contiguous
1093           device number allocation.
1094
1095           Note that turning on this debug option shuffles all the
1096           device numbers for all IDE and SCSI devices including libata
1097           ones, so root partition specified using device number
1098           directly (via rdev or root=MAJ:MIN) won't work anymore.
1099           Textual device names (root=/dev/sdXn) will continue to work.
1100
1101           Say N if you are unsure.
1102
1103 config DEBUG_FORCE_WEAK_PER_CPU
1104         bool "Force weak per-cpu definitions"
1105         depends on DEBUG_KERNEL
1106         help
1107           s390 and alpha require percpu variables in modules to be
1108           defined weak to work around addressing range issue which
1109           puts the following two restrictions on percpu variable
1110           definitions.
1111
1112           1. percpu symbols must be unique whether static or not
1113           2. percpu variables can't be defined inside a function
1114
1115           To ensure that generic code follows the above rules, this
1116           option forces all percpu variables to be defined as weak.
1117
1118 config DEBUG_PER_CPU_MAPS
1119         bool "Debug access to per_cpu maps"
1120         depends on DEBUG_KERNEL
1121         depends on SMP
1122         help
1123           Say Y to verify that the per_cpu map being accessed has
1124           been set up. This adds a fair amount of code to kernel memory
1125           and decreases performance.
1126
1127           Say N if unsure.
1128
1129 config LKDTM
1130         tristate "Linux Kernel Dump Test Tool Module"
1131         depends on DEBUG_FS
1132         depends on BLOCK
1133         default n
1134         help
1135         This module enables testing of the different dumping mechanisms by
1136         inducing system failures at predefined crash points.
1137         If you don't need it: say N
1138         Choose M here to compile this code as a module. The module will be
1139         called lkdtm.
1140
1141         Documentation on how to use the module can be found in
1142         Documentation/fault-injection/provoke-crashes.txt
1143
1144 config NOTIFIER_ERROR_INJECTION
1145         tristate "Notifier error injection"
1146         depends on DEBUG_KERNEL
1147         select DEBUG_FS
1148         help
1149           This option provides the ability to inject artificial errors to
1150           specified notifier chain callbacks. It is useful to test the error
1151           handling of notifier call chain failures.
1152
1153           Say N if unsure.
1154
1155 config CPU_NOTIFIER_ERROR_INJECT
1156         tristate "CPU notifier error injection module"
1157         depends on HOTPLUG_CPU && NOTIFIER_ERROR_INJECTION
1158         help
1159           This option provides a kernel module that can be used to test
1160           the error handling of the cpu notifiers by injecting artificial
1161           errors to CPU notifier chain callbacks.  It is controlled through
1162           debugfs interface under /sys/kernel/debug/notifier-error-inject/cpu
1163
1164           If the notifier call chain should be failed with some events
1165           notified, write the error code to "actions/<notifier event>/error".
1166
1167           Example: Inject CPU offline error (-1 == -EPERM)
1168
1169           # cd /sys/kernel/debug/notifier-error-inject/cpu
1170           # echo -1 > actions/CPU_DOWN_PREPARE/error
1171           # echo 0 > /sys/devices/system/cpu/cpu1/online
1172           bash: echo: write error: Operation not permitted
1173
1174           To compile this code as a module, choose M here: the module will
1175           be called cpu-notifier-error-inject.
1176
1177           If unsure, say N.
1178
1179 config PM_NOTIFIER_ERROR_INJECT
1180         tristate "PM notifier error injection module"
1181         depends on PM && NOTIFIER_ERROR_INJECTION
1182         default m if PM_DEBUG
1183         help
1184           This option provides the ability to inject artificial errors to
1185           PM notifier chain callbacks.  It is controlled through debugfs
1186           interface /sys/kernel/debug/notifier-error-inject/pm
1187
1188           If the notifier call chain should be failed with some events
1189           notified, write the error code to "actions/<notifier event>/error".
1190
1191           Example: Inject PM suspend error (-12 = -ENOMEM)
1192
1193           # cd /sys/kernel/debug/notifier-error-inject/pm/
1194           # echo -12 > actions/PM_SUSPEND_PREPARE/error
1195           # echo mem > /sys/power/state
1196           bash: echo: write error: Cannot allocate memory
1197
1198           To compile this code as a module, choose M here: the module will
1199           be called pm-notifier-error-inject.
1200
1201           If unsure, say N.
1202
1203 config MEMORY_NOTIFIER_ERROR_INJECT
1204         tristate "Memory hotplug notifier error injection module"
1205         depends on MEMORY_HOTPLUG_SPARSE && NOTIFIER_ERROR_INJECTION
1206         help
1207           This option provides the ability to inject artificial errors to
1208           memory hotplug notifier chain callbacks.  It is controlled through
1209           debugfs interface under /sys/kernel/debug/notifier-error-inject/memory
1210
1211           If the notifier call chain should be failed with some events
1212           notified, write the error code to "actions/<notifier event>/error".
1213
1214           Example: Inject memory hotplug offline error (-12 == -ENOMEM)
1215
1216           # cd /sys/kernel/debug/notifier-error-inject/memory
1217           # echo -12 > actions/MEM_GOING_OFFLINE/error
1218           # echo offline > /sys/devices/system/memory/memoryXXX/state
1219           bash: echo: write error: Cannot allocate memory
1220
1221           To compile this code as a module, choose M here: the module will
1222           be called memory-notifier-error-inject.
1223
1224           If unsure, say N.
1225
1226 config OF_RECONFIG_NOTIFIER_ERROR_INJECT
1227         tristate "OF reconfig notifier error injection module"
1228         depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION
1229         help
1230           This option provides the ability to inject artificial errors to
1231           OF reconfig notifier chain callbacks.  It is controlled
1232           through debugfs interface under
1233           /sys/kernel/debug/notifier-error-inject/OF-reconfig/
1234
1235           If the notifier call chain should be failed with some events
1236           notified, write the error code to "actions/<notifier event>/error".
1237
1238           To compile this code as a module, choose M here: the module will
1239           be called of-reconfig-notifier-error-inject.
1240
1241           If unsure, say N.
1242
1243 config FAULT_INJECTION
1244         bool "Fault-injection framework"
1245         depends on DEBUG_KERNEL
1246         help
1247           Provide fault-injection framework.
1248           For more details, see Documentation/fault-injection/.
1249
1250 config FAILSLAB
1251         bool "Fault-injection capability for kmalloc"
1252         depends on FAULT_INJECTION
1253         depends on SLAB || SLUB
1254         help
1255           Provide fault-injection capability for kmalloc.
1256
1257 config FAIL_PAGE_ALLOC
1258         bool "Fault-injection capabilitiy for alloc_pages()"
1259         depends on FAULT_INJECTION
1260         help
1261           Provide fault-injection capability for alloc_pages().
1262
1263 config FAIL_MAKE_REQUEST
1264         bool "Fault-injection capability for disk IO"
1265         depends on FAULT_INJECTION && BLOCK
1266         help
1267           Provide fault-injection capability for disk IO.
1268
1269 config FAIL_IO_TIMEOUT
1270         bool "Fault-injection capability for faking disk interrupts"
1271         depends on FAULT_INJECTION && BLOCK
1272         help
1273           Provide fault-injection capability on end IO handling. This
1274           will make the block layer "forget" an interrupt as configured,
1275           thus exercising the error handling.
1276
1277           Only works with drivers that use the generic timeout handling,
1278           for others it wont do anything.
1279
1280 config FAIL_MMC_REQUEST
1281         bool "Fault-injection capability for MMC IO"
1282         select DEBUG_FS
1283         depends on FAULT_INJECTION && MMC
1284         help
1285           Provide fault-injection capability for MMC IO.
1286           This will make the mmc core return data errors. This is
1287           useful to test the error handling in the mmc block device
1288           and to test how the mmc host driver handles retries from
1289           the block device.
1290
1291 config FAULT_INJECTION_DEBUG_FS
1292         bool "Debugfs entries for fault-injection capabilities"
1293         depends on FAULT_INJECTION && SYSFS && DEBUG_FS
1294         help
1295           Enable configuration of fault-injection capabilities via debugfs.
1296
1297 config FAULT_INJECTION_STACKTRACE_FILTER
1298         bool "stacktrace filter for fault-injection capabilities"
1299         depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT
1300         depends on !X86_64
1301         select STACKTRACE
1302         select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND
1303         help
1304           Provide stacktrace filter for fault-injection capabilities
1305
1306 config LATENCYTOP
1307         bool "Latency measuring infrastructure"
1308         depends on HAVE_LATENCYTOP_SUPPORT
1309         depends on DEBUG_KERNEL
1310         depends on STACKTRACE_SUPPORT
1311         depends on PROC_FS
1312         select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND
1313         select KALLSYMS
1314         select KALLSYMS_ALL
1315         select STACKTRACE
1316         select SCHEDSTATS
1317         select SCHED_DEBUG
1318         help
1319           Enable this option if you want to use the LatencyTOP tool
1320           to find out which userspace is blocking on what kernel operations.
1321
1322 config ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
1323         bool
1324
1325 config DEBUG_STRICT_USER_COPY_CHECKS
1326         bool "Strict user copy size checks"
1327         depends on ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
1328         depends on DEBUG_KERNEL && !TRACE_BRANCH_PROFILING
1329         help
1330           Enabling this option turns a certain set of sanity checks for user
1331           copy operations into compile time failures.
1332
1333           The copy_from_user() etc checks are there to help test if there
1334           are sufficient security checks on the length argument of
1335           the copy operation, by having gcc prove that the argument is
1336           within bounds.
1337
1338           If unsure, say N.
1339
1340 source mm/Kconfig.debug
1341 source kernel/trace/Kconfig
1342
1343 config RBTREE_TEST
1344         tristate "Red-Black tree test"
1345         depends on m && DEBUG_KERNEL
1346         help
1347           A benchmark measuring the performance of the rbtree library.
1348           Also includes rbtree invariant checks.
1349
1350 config INTERVAL_TREE_TEST
1351         tristate "Interval tree test"
1352         depends on m && DEBUG_KERNEL
1353         help
1354           A benchmark measuring the performance of the interval tree library
1355
1356 config PROVIDE_OHCI1394_DMA_INIT
1357         bool "Remote debugging over FireWire early on boot"
1358         depends on PCI && X86
1359         help
1360           If you want to debug problems which hang or crash the kernel early
1361           on boot and the crashing machine has a FireWire port, you can use
1362           this feature to remotely access the memory of the crashed machine
1363           over FireWire. This employs remote DMA as part of the OHCI1394
1364           specification which is now the standard for FireWire controllers.
1365
1366           With remote DMA, you can monitor the printk buffer remotely using
1367           firescope and access all memory below 4GB using fireproxy from gdb.
1368           Even controlling a kernel debugger is possible using remote DMA.
1369
1370           Usage:
1371
1372           If ohci1394_dma=early is used as boot parameter, it will initialize
1373           all OHCI1394 controllers which are found in the PCI config space.
1374
1375           As all changes to the FireWire bus such as enabling and disabling
1376           devices cause a bus reset and thereby disable remote DMA for all
1377           devices, be sure to have the cable plugged and FireWire enabled on
1378           the debugging host before booting the debug target for debugging.
1379
1380           This code (~1k) is freed after boot. By then, the firewire stack
1381           in charge of the OHCI-1394 controllers should be used instead.
1382
1383           See Documentation/debugging-via-ohci1394.txt for more information.
1384
1385 config FIREWIRE_OHCI_REMOTE_DMA
1386         bool "Remote debugging over FireWire with firewire-ohci"
1387         depends on FIREWIRE_OHCI
1388         help
1389           This option lets you use the FireWire bus for remote debugging
1390           with help of the firewire-ohci driver. It enables unfiltered
1391           remote DMA in firewire-ohci.
1392           See Documentation/debugging-via-ohci1394.txt for more information.
1393
1394           If unsure, say N.
1395
1396 config BUILD_DOCSRC
1397         bool "Build targets in Documentation/ tree"
1398         depends on HEADERS_CHECK
1399         help
1400           This option attempts to build objects from the source files in the
1401           kernel Documentation/ tree.
1402
1403           Say N if you are unsure.
1404
1405 config DYNAMIC_DEBUG
1406         bool "Enable dynamic printk() support"
1407         default n
1408         depends on PRINTK
1409         depends on DEBUG_FS
1410         help
1411
1412           Compiles debug level messages into the kernel, which would not
1413           otherwise be available at runtime. These messages can then be
1414           enabled/disabled based on various levels of scope - per source file,
1415           function, module, format string, and line number. This mechanism
1416           implicitly compiles in all pr_debug() and dev_dbg() calls, which
1417           enlarges the kernel text size by about 2%.
1418
1419           If a source file is compiled with DEBUG flag set, any
1420           pr_debug() calls in it are enabled by default, but can be
1421           disabled at runtime as below.  Note that DEBUG flag is
1422           turned on by many CONFIG_*DEBUG* options.
1423
1424           Usage:
1425
1426           Dynamic debugging is controlled via the 'dynamic_debug/control' file,
1427           which is contained in the 'debugfs' filesystem. Thus, the debugfs
1428           filesystem must first be mounted before making use of this feature.
1429           We refer the control file as: <debugfs>/dynamic_debug/control. This
1430           file contains a list of the debug statements that can be enabled. The
1431           format for each line of the file is:
1432
1433                 filename:lineno [module]function flags format
1434
1435           filename : source file of the debug statement
1436           lineno : line number of the debug statement
1437           module : module that contains the debug statement
1438           function : function that contains the debug statement
1439           flags : '=p' means the line is turned 'on' for printing
1440           format : the format used for the debug statement
1441
1442           From a live system:
1443
1444                 nullarbor:~ # cat <debugfs>/dynamic_debug/control
1445                 # filename:lineno [module]function flags format
1446                 fs/aio.c:222 [aio]__put_ioctx =_ "__put_ioctx:\040freeing\040%p\012"
1447                 fs/aio.c:248 [aio]ioctx_alloc =_ "ENOMEM:\040nr_events\040too\040high\012"
1448                 fs/aio.c:1770 [aio]sys_io_cancel =_ "calling\040cancel\012"
1449
1450           Example usage:
1451
1452                 // enable the message at line 1603 of file svcsock.c
1453                 nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >
1454                                                 <debugfs>/dynamic_debug/control
1455
1456                 // enable all the messages in file svcsock.c
1457                 nullarbor:~ # echo -n 'file svcsock.c +p' >
1458                                                 <debugfs>/dynamic_debug/control
1459
1460                 // enable all the messages in the NFS server module
1461                 nullarbor:~ # echo -n 'module nfsd +p' >
1462                                                 <debugfs>/dynamic_debug/control
1463
1464                 // enable all 12 messages in the function svc_process()
1465                 nullarbor:~ # echo -n 'func svc_process +p' >
1466                                                 <debugfs>/dynamic_debug/control
1467
1468                 // disable all 12 messages in the function svc_process()
1469                 nullarbor:~ # echo -n 'func svc_process -p' >
1470                                                 <debugfs>/dynamic_debug/control
1471
1472           See Documentation/dynamic-debug-howto.txt for additional information.
1473
1474 config DMA_API_DEBUG
1475         bool "Enable debugging of DMA-API usage"
1476         depends on HAVE_DMA_API_DEBUG
1477         help
1478           Enable this option to debug the use of the DMA API by device drivers.
1479           With this option you will be able to detect common bugs in device
1480           drivers like double-freeing of DMA mappings or freeing mappings that
1481           were never allocated.
1482           This option causes a performance degredation.  Use only if you want
1483           to debug device drivers. If unsure, say N.
1484
1485 config ATOMIC64_SELFTEST
1486         bool "Perform an atomic64_t self-test at boot"
1487         help
1488           Enable this option to test the atomic64_t functions at boot.
1489
1490           If unsure, say N.
1491
1492 config ASYNC_RAID6_TEST
1493         tristate "Self test for hardware accelerated raid6 recovery"
1494         depends on ASYNC_RAID6_RECOV
1495         select ASYNC_MEMCPY
1496         ---help---
1497           This is a one-shot self test that permutes through the
1498           recovery of all the possible two disk failure scenarios for a
1499           N-disk array.  Recovery is performed with the asynchronous
1500           raid6 recovery routines, and will optionally use an offload
1501           engine if one is available.
1502
1503           If unsure, say N.
1504
1505 source "samples/Kconfig"
1506
1507 source "lib/Kconfig.kgdb"
1508
1509 source "lib/Kconfig.kmemcheck"
1510
1511 config TEST_STRING_HELPERS
1512         tristate "Test functions located in the string_helpers module at runtime"
1513
1514 config TEST_KSTRTOX
1515         tristate "Test kstrto*() family of functions at runtime"
1516
1517 config TIME_HISTORY
1518         bool "Collect kernel time setting and alarm infomation"
1519         depends on DEBUG_KERNEL && PROC_FS
1520         help
1521           If you say Y here, additional code will be inserted into the
1522           time/alarm routines to collect history about kernel time/alarms.
1523           The alarm history can be read from /sys/kernel/debug/alarm_history.
1524           This feature is useful to debug time/alarm.
1525
1526 config TIME_HISTORY_SAVE_BOOTTIME
1527         bool "Save log boot time"
1528         depends on TIME_HISTORY
1529         default n
1530         help
1531                 If you say Y hear, save boottime of logs.
1532                 It uses additional 8bytes memory space for each log entry
1533
1534 config TIME_HISTORY_LOG_FILTER
1535         depends on TIME_HISTORY
1536         bool "Filtering specific logs"
1537         default y
1538         help
1539                 If you say Y hear, do not save specific logs