Root/lib/Kconfig.debug

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

Archive Download this file



interactive