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 DEBUG_KERNEL
316    bool "Kernel debugging"
317    help
318      Say Y here if you are developing drivers or trying to debug and
319      identify kernel problems.
320
321menu "Memory Debugging"
322
323source mm/Kconfig.debug
324
325config DEBUG_OBJECTS
326    bool "Debug object operations"
327    depends on DEBUG_KERNEL
328    help
329      If you say Y here, additional code will be inserted into the
330      kernel to track the life time of various objects and validate
331      the operations on those objects.
332
333config DEBUG_OBJECTS_SELFTEST
334    bool "Debug objects selftest"
335    depends on DEBUG_OBJECTS
336    help
337      This enables the selftest of the object debug code.
338
339config DEBUG_OBJECTS_FREE
340    bool "Debug objects in freed memory"
341    depends on DEBUG_OBJECTS
342    help
343      This enables checks whether a k/v free operation frees an area
344      which contains an object which has not been deactivated
345      properly. This can make kmalloc/kfree-intensive workloads
346      much slower.
347
348config DEBUG_OBJECTS_TIMERS
349    bool "Debug timer objects"
350    depends on DEBUG_OBJECTS
351    help
352      If you say Y here, additional code will be inserted into the
353      timer routines to track the life time of timer objects and
354      validate the timer operations.
355
356config DEBUG_OBJECTS_WORK
357    bool "Debug work objects"
358    depends on DEBUG_OBJECTS
359    help
360      If you say Y here, additional code will be inserted into the
361      work queue routines to track the life time of work objects and
362      validate the work operations.
363
364config DEBUG_OBJECTS_RCU_HEAD
365    bool "Debug RCU callbacks objects"
366    depends on DEBUG_OBJECTS
367    help
368      Enable this to turn on debugging of RCU list heads (call_rcu() usage).
369
370config DEBUG_OBJECTS_PERCPU_COUNTER
371    bool "Debug percpu counter objects"
372    depends on DEBUG_OBJECTS
373    help
374      If you say Y here, additional code will be inserted into the
375      percpu counter routines to track the life time of percpu counter
376      objects and validate the percpu counter operations.
377
378config DEBUG_OBJECTS_ENABLE_DEFAULT
379    int "debug_objects bootup default value (0-1)"
380        range 0 1
381        default "1"
382        depends on DEBUG_OBJECTS
383        help
384          Debug objects boot parameter default value
385
386config DEBUG_SLAB
387    bool "Debug slab memory allocations"
388    depends on DEBUG_KERNEL && SLAB && !KMEMCHECK
389    help
390      Say Y here to have the kernel do limited verification on memory
391      allocation as well as poisoning memory on free to catch use of freed
392      memory. This can make kmalloc/kfree-intensive workloads much slower.
393
394config DEBUG_SLAB_LEAK
395    bool "Memory leak debugging"
396    depends on DEBUG_SLAB
397
398config SLUB_DEBUG_ON
399    bool "SLUB debugging on by default"
400    depends on SLUB && SLUB_DEBUG && !KMEMCHECK
401    default n
402    help
403      Boot with debugging on by default. SLUB boots by default with
404      the runtime debug capabilities switched off. Enabling this is
405      equivalent to specifying the "slub_debug" parameter on boot.
406      There is no support for more fine grained debug control like
407      possible with slub_debug=xxx. SLUB debugging may be switched
408      off in a kernel built with CONFIG_SLUB_DEBUG_ON by specifying
409      "slub_debug=-".
410
411config SLUB_STATS
412    default n
413    bool "Enable SLUB performance statistics"
414    depends on SLUB && SYSFS
415    help
416      SLUB statistics are useful to debug SLUBs allocation behavior in
417      order find ways to optimize the allocator. This should never be
418      enabled for production use since keeping statistics slows down
419      the allocator by a few percentage points. The slabinfo command
420      supports the determination of the most active slabs to figure
421      out which slabs are relevant to a particular load.
422      Try running: slabinfo -DA
423
424config HAVE_DEBUG_KMEMLEAK
425    bool
426
427config DEBUG_KMEMLEAK
428    bool "Kernel memory leak detector"
429    depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK
430    select DEBUG_FS
431    select STACKTRACE if STACKTRACE_SUPPORT
432    select KALLSYMS
433    select CRC32
434    help
435      Say Y here if you want to enable the memory leak
436      detector. The memory allocation/freeing is traced in a way
437      similar to the Boehm's conservative garbage collector, the
438      difference being that the orphan objects are not freed but
439      only shown in /sys/kernel/debug/kmemleak. Enabling this
440      feature will introduce an overhead to memory
441      allocations. See Documentation/kmemleak.txt for more
442      details.
443
444      Enabling DEBUG_SLAB or SLUB_DEBUG may increase the chances
445      of finding leaks due to the slab objects poisoning.
446
447      In order to access the kmemleak file, debugfs needs to be
448      mounted (usually at /sys/kernel/debug).
449
450config DEBUG_KMEMLEAK_EARLY_LOG_SIZE
451    int "Maximum kmemleak early log entries"
452    depends on DEBUG_KMEMLEAK
453    range 200 40000
454    default 400
455    help
456      Kmemleak must track all the memory allocations to avoid
457      reporting false positives. Since memory may be allocated or
458      freed before kmemleak is initialised, an early log buffer is
459      used to store these actions. If kmemleak reports "early log
460      buffer exceeded", please increase this value.
461
462config DEBUG_KMEMLEAK_TEST
463    tristate "Simple test for the kernel memory leak detector"
464    depends on DEBUG_KMEMLEAK && m
465    help
466      This option enables a module that explicitly leaks memory.
467
468      If unsure, say N.
469
470config DEBUG_KMEMLEAK_DEFAULT_OFF
471    bool "Default kmemleak to off"
472    depends on DEBUG_KMEMLEAK
473    help
474      Say Y here to disable kmemleak by default. It can then be enabled
475      on the command line via kmemleak=on.
476
477config DEBUG_STACK_USAGE
478    bool "Stack utilization instrumentation"
479    depends on DEBUG_KERNEL && !IA64 && !PARISC && !METAG
480    help
481      Enables the display of the minimum amount of free stack which each
482      task has ever had available in the sysrq-T and sysrq-P debug output.
483
484      This option will slow down process creation somewhat.
485
486config DEBUG_VM
487    bool "Debug VM"
488    depends on DEBUG_KERNEL
489    help
490      Enable this to turn on extended checks in the virtual-memory system
491          that may impact performance.
492
493      If unsure, say N.
494
495config DEBUG_VM_RB
496    bool "Debug VM red-black trees"
497    depends on DEBUG_VM
498    help
499      Enable this to turn on more extended checks in the virtual-memory
500      system that may impact performance.
501
502      If unsure, say N.
503
504config DEBUG_VIRTUAL
505    bool "Debug VM translations"
506    depends on DEBUG_KERNEL && X86
507    help
508      Enable some costly sanity checks in virtual to page code. This can
509      catch mistakes with virt_to_page() and friends.
510
511      If unsure, say N.
512
513config DEBUG_NOMMU_REGIONS
514    bool "Debug the global anon/private NOMMU mapping region tree"
515    depends on DEBUG_KERNEL && !MMU
516    help
517      This option causes the global tree of anonymous and private mapping
518      regions to be regularly checked for invalid topology.
519
520config DEBUG_MEMORY_INIT
521    bool "Debug memory initialisation" if EXPERT
522    default !EXPERT
523    help
524      Enable this for additional checks during memory initialisation.
525      The sanity checks verify aspects of the VM such as the memory model
526      and other information provided by the architecture. Verbose
527      information will be printed at KERN_DEBUG loglevel depending
528      on the mminit_loglevel= command-line option.
529
530      If unsure, say Y
531
532config MEMORY_NOTIFIER_ERROR_INJECT
533    tristate "Memory hotplug notifier error injection module"
534    depends on MEMORY_HOTPLUG_SPARSE && NOTIFIER_ERROR_INJECTION
535    help
536      This option provides the ability to inject artificial errors to
537      memory hotplug notifier chain callbacks. It is controlled through
538      debugfs interface under /sys/kernel/debug/notifier-error-inject/memory
539
540      If the notifier call chain should be failed with some events
541      notified, write the error code to "actions/<notifier event>/error".
542
543      Example: Inject memory hotplug offline error (-12 == -ENOMEM)
544
545      # cd /sys/kernel/debug/notifier-error-inject/memory
546      # echo -12 > actions/MEM_GOING_OFFLINE/error
547      # echo offline > /sys/devices/system/memory/memoryXXX/state
548      bash: echo: write error: Cannot allocate memory
549
550      To compile this code as a module, choose M here: the module will
551      be called memory-notifier-error-inject.
552
553      If unsure, say N.
554
555config DEBUG_PER_CPU_MAPS
556    bool "Debug access to per_cpu maps"
557    depends on DEBUG_KERNEL
558    depends on SMP
559    help
560      Say Y to verify that the per_cpu map being accessed has
561      been set up. This adds a fair amount of code to kernel memory
562      and decreases performance.
563
564      Say N if unsure.
565
566config DEBUG_HIGHMEM
567    bool "Highmem debugging"
568    depends on DEBUG_KERNEL && HIGHMEM
569    help
570      This options enables addition error checking for high memory systems.
571      Disable for production systems.
572
573config HAVE_DEBUG_STACKOVERFLOW
574    bool
575
576config DEBUG_STACKOVERFLOW
577    bool "Check for stack overflows"
578    depends on DEBUG_KERNEL && HAVE_DEBUG_STACKOVERFLOW
579    ---help---
580      Say Y here if you want to check for overflows of kernel, IRQ
581      and exception stacks (if your archicture uses them). This
582      option will show detailed messages if free stack space drops
583      below a certain limit.
584
585      These kinds of bugs usually occur when call-chains in the
586      kernel get too deep, especially when interrupts are
587      involved.
588
589      Use this in cases where you see apparently random memory
590      corruption, especially if it appears in 'struct thread_info'
591
592      If in doubt, say "N".
593
594source "lib/Kconfig.kmemcheck"
595
596endmenu # "Memory Debugging"
597
598config DEBUG_SHIRQ
599    bool "Debug shared IRQ handlers"
600    depends on DEBUG_KERNEL && GENERIC_HARDIRQS
601    help
602      Enable this to generate a spurious interrupt as soon as a shared
603      interrupt handler is registered, and just before one is deregistered.
604      Drivers ought to be able to handle interrupts coming in at those
605      points; some don't and need to be caught.
606
607menu "Debug Lockups and Hangs"
608
609config LOCKUP_DETECTOR
610    bool "Detect Hard and Soft Lockups"
611    depends on DEBUG_KERNEL && !S390
612    help
613      Say Y here to enable the kernel to act as a watchdog to detect
614      hard and soft lockups.
615
616      Softlockups are bugs that cause the kernel to loop in kernel
617      mode for more than 20 seconds, without giving other tasks a
618      chance to run. The current stack trace is displayed upon
619      detection and the system will stay locked up.
620
621      Hardlockups are bugs that cause the CPU to loop in kernel mode
622      for more than 10 seconds, without letting other interrupts have a
623      chance to run. The current stack trace is displayed upon detection
624      and the system will stay locked up.
625
626      The overhead should be minimal. A periodic hrtimer runs to
627      generate interrupts and kick the watchdog task every 4 seconds.
628      An NMI is generated every 10 seconds or so to check for hardlockups.
629
630      The frequency of hrtimer and NMI events and the soft and hard lockup
631      thresholds can be controlled through the sysctl watchdog_thresh.
632
633config HARDLOCKUP_DETECTOR
634    def_bool y
635    depends on LOCKUP_DETECTOR && !HAVE_NMI_WATCHDOG
636    depends on PERF_EVENTS && HAVE_PERF_EVENTS_NMI
637
638config BOOTPARAM_HARDLOCKUP_PANIC
639    bool "Panic (Reboot) On Hard Lockups"
640    depends on HARDLOCKUP_DETECTOR
641    help
642      Say Y here to enable the kernel to panic on "hard lockups",
643      which are bugs that cause the kernel to loop in kernel
644      mode with interrupts disabled for more than 10 seconds (configurable
645      using the watchdog_thresh sysctl).
646
647      Say N if unsure.
648
649config BOOTPARAM_HARDLOCKUP_PANIC_VALUE
650    int
651    depends on HARDLOCKUP_DETECTOR
652    range 0 1
653    default 0 if !BOOTPARAM_HARDLOCKUP_PANIC
654    default 1 if BOOTPARAM_HARDLOCKUP_PANIC
655
656config BOOTPARAM_SOFTLOCKUP_PANIC
657    bool "Panic (Reboot) On Soft Lockups"
658    depends on LOCKUP_DETECTOR
659    help
660      Say Y here to enable the kernel to panic on "soft lockups",
661      which are bugs that cause the kernel to loop in kernel
662      mode for more than 20 seconds (configurable using the watchdog_thresh
663      sysctl), without giving other tasks a chance to run.
664
665      The panic can be used in combination with panic_timeout,
666      to cause the system to reboot automatically after a
667      lockup has been detected. This feature is useful for
668      high-availability systems that have uptime guarantees and
669      where a lockup must be resolved ASAP.
670
671      Say N if unsure.
672
673config BOOTPARAM_SOFTLOCKUP_PANIC_VALUE
674    int
675    depends on LOCKUP_DETECTOR
676    range 0 1
677    default 0 if !BOOTPARAM_SOFTLOCKUP_PANIC
678    default 1 if BOOTPARAM_SOFTLOCKUP_PANIC
679
680config DETECT_HUNG_TASK
681    bool "Detect Hung Tasks"
682    depends on DEBUG_KERNEL
683    default LOCKUP_DETECTOR
684    help
685      Say Y here to enable the kernel to detect "hung tasks",
686      which are bugs that cause the task to be stuck in
687      uninterruptible "D" state indefinitiley.
688
689      When a hung task is detected, the kernel will print the
690      current stack trace (which you should report), but the
691      task will stay in uninterruptible state. If lockdep is
692      enabled then all held locks will also be reported. This
693      feature has negligible overhead.
694
695config DEFAULT_HUNG_TASK_TIMEOUT
696    int "Default timeout for hung task detection (in seconds)"
697    depends on DETECT_HUNG_TASK
698    default 120
699    help
700      This option controls the default timeout (in seconds) used
701      to determine when a task has become non-responsive and should
702      be considered hung.
703
704      It can be adjusted at runtime via the kernel.hung_task_timeout_secs
705      sysctl or by writing a value to
706      /proc/sys/kernel/hung_task_timeout_secs.
707
708      A timeout of 0 disables the check. The default is two minutes.
709      Keeping the default should be fine in most cases.
710
711config BOOTPARAM_HUNG_TASK_PANIC
712    bool "Panic (Reboot) On Hung Tasks"
713    depends on DETECT_HUNG_TASK
714    help
715      Say Y here to enable the kernel to panic on "hung tasks",
716      which are bugs that cause the kernel to leave a task stuck
717      in uninterruptible "D" state.
718
719      The panic can be used in combination with panic_timeout,
720      to cause the system to reboot automatically after a
721      hung task has been detected. This feature is useful for
722      high-availability systems that have uptime guarantees and
723      where a hung tasks must be resolved ASAP.
724
725      Say N if unsure.
726
727config BOOTPARAM_HUNG_TASK_PANIC_VALUE
728    int
729    depends on DETECT_HUNG_TASK
730    range 0 1
731    default 0 if !BOOTPARAM_HUNG_TASK_PANIC
732    default 1 if BOOTPARAM_HUNG_TASK_PANIC
733
734endmenu # "Debug lockups and hangs"
735
736config PANIC_ON_OOPS
737    bool "Panic on Oops"
738    help
739      Say Y here to enable the kernel to panic when it oopses. This
740      has the same effect as setting oops=panic on the kernel command
741      line.
742
743      This feature is useful to ensure that the kernel does not do
744      anything erroneous after an oops which could result in data
745      corruption or other issues.
746
747      Say N if unsure.
748
749config PANIC_ON_OOPS_VALUE
750    int
751    range 0 1
752    default 0 if !PANIC_ON_OOPS
753    default 1 if PANIC_ON_OOPS
754
755config SCHED_DEBUG
756    bool "Collect scheduler debugging info"
757    depends on DEBUG_KERNEL && PROC_FS
758    default y
759    help
760      If you say Y here, the /proc/sched_debug file will be provided
761      that can help debug the scheduler. The runtime overhead of this
762      option is minimal.
763
764config SCHEDSTATS
765    bool "Collect scheduler statistics"
766    depends on DEBUG_KERNEL && PROC_FS
767    help
768      If you say Y here, additional code will be inserted into the
769      scheduler and related routines to collect statistics about
770      scheduler behavior and provide them in /proc/schedstat. These
771      stats may be useful for both tuning and debugging the scheduler
772      If you aren't debugging the scheduler or trying to tune a specific
773      application, you can say N to avoid the very slight overhead
774      this adds.
775
776config TIMER_STATS
777    bool "Collect kernel timers statistics"
778    depends on DEBUG_KERNEL && PROC_FS
779    help
780      If you say Y here, additional code will be inserted into the
781      timer routines to collect statistics about kernel timers being
782      reprogrammed. The statistics can be read from /proc/timer_stats.
783      The statistics collection is started by writing 1 to /proc/timer_stats,
784      writing 0 stops it. This feature is useful to collect information
785      about timer usage patterns in kernel and userspace. This feature
786      is lightweight if enabled in the kernel config but not activated
787      (it defaults to deactivated on bootup and will only be activated
788      if some application like powertop activates it explicitly).
789
790config DEBUG_PREEMPT
791    bool "Debug preemptible kernel"
792    depends on DEBUG_KERNEL && PREEMPT && TRACE_IRQFLAGS_SUPPORT
793    default y
794    help
795      If you say Y here then the kernel will use a debug variant of the
796      commonly used smp_processor_id() function and will print warnings
797      if kernel code uses it in a preemption-unsafe way. Also, the kernel
798      will detect preemption count underflows.
799
800menu "Lock Debugging (spinlocks, mutexes, etc...)"
801
802config DEBUG_RT_MUTEXES
803    bool "RT Mutex debugging, deadlock detection"
804    depends on DEBUG_KERNEL && RT_MUTEXES
805    help
806     This allows rt mutex semantics violations and rt mutex related
807     deadlocks (lockups) to be detected and reported automatically.
808
809config DEBUG_PI_LIST
810    bool
811    default y
812    depends on DEBUG_RT_MUTEXES
813
814config RT_MUTEX_TESTER
815    bool "Built-in scriptable tester for rt-mutexes"
816    depends on DEBUG_KERNEL && RT_MUTEXES
817    help
818      This option enables a rt-mutex tester.
819
820config DEBUG_SPINLOCK
821    bool "Spinlock and rw-lock debugging: basic checks"
822    depends on DEBUG_KERNEL
823    select UNINLINE_SPIN_UNLOCK
824    help
825      Say Y here and build SMP to catch missing spinlock initialization
826      and certain other kinds of spinlock errors commonly made. This is
827      best used in conjunction with the NMI watchdog so that spinlock
828      deadlocks are also debuggable.
829
830config DEBUG_MUTEXES
831    bool "Mutex debugging: basic checks"
832    depends on DEBUG_KERNEL
833    help
834     This feature allows mutex semantics violations to be detected and
835     reported.
836
837config DEBUG_WW_MUTEX_SLOWPATH
838    bool "Wait/wound mutex debugging: Slowpath testing"
839    depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
840    select DEBUG_LOCK_ALLOC
841    select DEBUG_SPINLOCK
842    select DEBUG_MUTEXES
843    help
844     This feature enables slowpath testing for w/w mutex users by
845     injecting additional -EDEADLK wound/backoff cases. Together with
846     the full mutex checks enabled with (CONFIG_PROVE_LOCKING) this
847     will test all possible w/w mutex interface abuse with the
848     exception of simply not acquiring all the required locks.
849
850config DEBUG_LOCK_ALLOC
851    bool "Lock debugging: detect incorrect freeing of live locks"
852    depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
853    select DEBUG_SPINLOCK
854    select DEBUG_MUTEXES
855    select LOCKDEP
856    help
857     This feature will check whether any held lock (spinlock, rwlock,
858     mutex or rwsem) is incorrectly freed by the kernel, via any of the
859     memory-freeing routines (kfree(), kmem_cache_free(), free_pages(),
860     vfree(), etc.), whether a live lock is incorrectly reinitialized via
861     spin_lock_init()/mutex_init()/etc., or whether there is any lock
862     held during task exit.
863
864config PROVE_LOCKING
865    bool "Lock debugging: prove locking correctness"
866    depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
867    select LOCKDEP
868    select DEBUG_SPINLOCK
869    select DEBUG_MUTEXES
870    select DEBUG_LOCK_ALLOC
871    select TRACE_IRQFLAGS
872    default n
873    help
874     This feature enables the kernel to prove that all locking
875     that occurs in the kernel runtime is mathematically
876     correct: that under no circumstance could an arbitrary (and
877     not yet triggered) combination of observed locking
878     sequences (on an arbitrary number of CPUs, running an
879     arbitrary number of tasks and interrupt contexts) cause a
880     deadlock.
881
882     In short, this feature enables the kernel to report locking
883     related deadlocks before they actually occur.
884
885     The proof does not depend on how hard and complex a
886     deadlock scenario would be to trigger: how many
887     participant CPUs, tasks and irq-contexts would be needed
888     for it to trigger. The proof also does not depend on
889     timing: if a race and a resulting deadlock is possible
890     theoretically (no matter how unlikely the race scenario
891     is), it will be proven so and will immediately be
892     reported by the kernel (once the event is observed that
893     makes the deadlock theoretically possible).
894
895     If a deadlock is impossible (i.e. the locking rules, as
896     observed by the kernel, are mathematically correct), the
897     kernel reports nothing.
898
899     NOTE: this feature can also be enabled for rwlocks, mutexes
900     and rwsems - in which case all dependencies between these
901     different locking variants are observed and mapped too, and
902     the proof of observed correctness is also maintained for an
903     arbitrary combination of these separate locking variants.
904
905     For more details, see Documentation/lockdep-design.txt.
906
907config LOCKDEP
908    bool
909    depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
910    select STACKTRACE
911    select FRAME_POINTER if !MIPS && !PPC && !ARM_UNWIND && !S390 && !MICROBLAZE
912    select KALLSYMS
913    select KALLSYMS_ALL
914
915config LOCK_STAT
916    bool "Lock usage statistics"
917    depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
918    select LOCKDEP
919    select DEBUG_SPINLOCK
920    select DEBUG_MUTEXES
921    select DEBUG_LOCK_ALLOC
922    default n
923    help
924     This feature enables tracking lock contention points
925
926     For more details, see Documentation/lockstat.txt
927
928     This also enables lock events required by "perf lock",
929     subcommand of perf.
930     If you want to use "perf lock", you also need to turn on
931     CONFIG_EVENT_TRACING.
932
933     CONFIG_LOCK_STAT defines "contended" and "acquired" lock events.
934     (CONFIG_LOCKDEP defines "acquire" and "release" events.)
935
936config DEBUG_LOCKDEP
937    bool "Lock dependency engine debugging"
938    depends on DEBUG_KERNEL && LOCKDEP
939    help
940      If you say Y here, the lock dependency engine will do
941      additional runtime checks to debug itself, at the price
942      of more runtime overhead.
943
944config DEBUG_ATOMIC_SLEEP
945    bool "Sleep inside atomic section checking"
946    select PREEMPT_COUNT
947    depends on DEBUG_KERNEL
948    help
949      If you say Y here, various routines which may sleep will become very
950      noisy if they are called inside atomic sections: when a spinlock is
951      held, inside an rcu read side critical section, inside preempt disabled
952      sections, inside an interrupt, etc...
953
954config DEBUG_LOCKING_API_SELFTESTS
955    bool "Locking API boot-time self-tests"
956    depends on DEBUG_KERNEL
957    help
958      Say Y here if you want the kernel to run a short self-test during
959      bootup. The self-test checks whether common types of locking bugs
960      are detected by debugging mechanisms or not. (if you disable
961      lock debugging then those bugs wont be detected of course.)
962      The following locking APIs are covered: spinlocks, rwlocks,
963      mutexes and rwsems.
964
965endmenu # lock debugging
966
967config TRACE_IRQFLAGS
968    bool
969    help
970      Enables hooks to interrupt enabling and disabling for
971      either tracing or lock debugging.
972
973config STACKTRACE
974    bool
975    depends on STACKTRACE_SUPPORT
976
977config DEBUG_KOBJECT
978    bool "kobject debugging"
979    depends on DEBUG_KERNEL
980    help
981      If you say Y here, some extra kobject debugging messages will be sent
982      to the syslog.
983
984config HAVE_DEBUG_BUGVERBOSE
985    bool
986
987config DEBUG_BUGVERBOSE
988    bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
989    depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
990    default y
991    help
992      Say Y here to make BUG() panics output the file name and line number
993      of the BUG call as well as the EIP and oops trace. This aids
994      debugging but costs about 70-100K of memory.
995
996config DEBUG_WRITECOUNT
997    bool "Debug filesystem writers count"
998    depends on DEBUG_KERNEL
999    help
1000      Enable this to catch wrong use of the writers count in struct
1001      vfsmount. This will increase the size of each file struct by
1002      32 bits.
1003
1004      If unsure, say N.
1005
1006config DEBUG_LIST
1007    bool "Debug linked list manipulation"
1008    depends on DEBUG_KERNEL
1009    help
1010      Enable this to turn on extended checks in the linked-list
1011      walking routines.
1012
1013      If unsure, say N.
1014
1015config DEBUG_SG
1016    bool "Debug SG table operations"
1017    depends on DEBUG_KERNEL
1018    help
1019      Enable this to turn on checks on scatter-gather tables. This can
1020      help find problems with drivers that do not properly initialize
1021      their sg tables.
1022
1023      If unsure, say N.
1024
1025config DEBUG_NOTIFIERS
1026    bool "Debug notifier call chains"
1027    depends on DEBUG_KERNEL
1028    help
1029      Enable this to turn on sanity checking for notifier call chains.
1030      This is most useful for kernel developers to make sure that
1031      modules properly unregister themselves from notifier chains.
1032      This is a relatively cheap check but if you care about maximum
1033      performance, say N.
1034
1035config DEBUG_CREDENTIALS
1036    bool "Debug credential management"
1037    depends on DEBUG_KERNEL
1038    help
1039      Enable this to turn on some debug checking for credential
1040      management. The additional code keeps track of the number of
1041      pointers from task_structs to any given cred struct, and checks to
1042      see that this number never exceeds the usage count of the cred
1043      struct.
1044
1045      Furthermore, if SELinux is enabled, this also checks that the
1046      security pointer in the cred struct is never seen to be invalid.
1047
1048      If unsure, say N.
1049
1050menu "RCU Debugging"
1051
1052config PROVE_RCU
1053    bool "RCU debugging: prove RCU correctness"
1054    depends on PROVE_LOCKING
1055    default n
1056    help
1057     This feature enables lockdep extensions that check for correct
1058     use of RCU APIs. This is currently under development. Say Y
1059     if you want to debug RCU usage or help work on the PROVE_RCU
1060     feature.
1061
1062     Say N if you are unsure.
1063
1064config PROVE_RCU_REPEATEDLY
1065    bool "RCU debugging: don't disable PROVE_RCU on first splat"
1066    depends on PROVE_RCU
1067    default n
1068    help
1069     By itself, PROVE_RCU will disable checking upon issuing the
1070     first warning (or "splat"). This feature prevents such
1071     disabling, allowing multiple RCU-lockdep warnings to be printed
1072     on a single reboot.
1073
1074     Say Y to allow multiple RCU-lockdep warnings per boot.
1075
1076     Say N if you are unsure.
1077
1078config PROVE_RCU_DELAY
1079    bool "RCU debugging: preemptible RCU race provocation"
1080    depends on DEBUG_KERNEL && PREEMPT_RCU
1081    default n
1082    help
1083     There is a class of races that involve an unlikely preemption
1084     of __rcu_read_unlock() just after ->rcu_read_lock_nesting has
1085     been set to INT_MIN. This feature inserts a delay at that
1086     point to increase the probability of these races.
1087
1088     Say Y to increase probability of preemption of __rcu_read_unlock().
1089
1090     Say N if you are unsure.
1091
1092config SPARSE_RCU_POINTER
1093    bool "RCU debugging: sparse-based checks for pointer usage"
1094    default n
1095    help
1096     This feature enables the __rcu sparse annotation for
1097     RCU-protected pointers. This annotation will cause sparse
1098     to flag any non-RCU used of annotated pointers. This can be
1099     helpful when debugging RCU usage. Please note that this feature
1100     is not intended to enforce code cleanliness; it is instead merely
1101     a debugging aid.
1102
1103     Say Y to make sparse flag questionable use of RCU-protected pointers
1104
1105     Say N if you are unsure.
1106
1107config RCU_TORTURE_TEST
1108    tristate "torture tests for RCU"
1109    depends on DEBUG_KERNEL
1110    default n
1111    help
1112      This option provides a kernel module that runs torture tests
1113      on the RCU infrastructure. The kernel module may be built
1114      after the fact on the running kernel to be tested, if desired.
1115
1116      Say Y here if you want RCU torture tests to be built into
1117      the kernel.
1118      Say M if you want the RCU torture tests to build as a module.
1119      Say N if you are unsure.
1120
1121config RCU_TORTURE_TEST_RUNNABLE
1122    bool "torture tests for RCU runnable by default"
1123    depends on RCU_TORTURE_TEST = y
1124    default n
1125    help
1126      This option provides a way to build the RCU torture tests
1127      directly into the kernel without them starting up at boot
1128      time. You can use /proc/sys/kernel/rcutorture_runnable
1129      to manually override this setting. This /proc file is
1130      available only when the RCU torture tests have been built
1131      into the kernel.
1132
1133      Say Y here if you want the RCU torture tests to start during
1134      boot (you probably don't).
1135      Say N here if you want the RCU torture tests to start only
1136      after being manually enabled via /proc.
1137
1138config RCU_CPU_STALL_TIMEOUT
1139    int "RCU CPU stall timeout in seconds"
1140    depends on RCU_STALL_COMMON
1141    range 3 300
1142    default 21
1143    help
1144      If a given RCU grace period extends more than the specified
1145      number of seconds, a CPU stall warning is printed. If the
1146      RCU grace period persists, additional CPU stall warnings are
1147      printed at more widely spaced intervals.
1148
1149config RCU_CPU_STALL_VERBOSE
1150    bool "Print additional per-task information for RCU_CPU_STALL_DETECTOR"
1151    depends on TREE_PREEMPT_RCU
1152    default y
1153    help
1154      This option causes RCU to printk detailed per-task information
1155      for any tasks that are stalling the current RCU grace period.
1156
1157      Say N if you are unsure.
1158
1159      Say Y if you want to enable such checks.
1160
1161config RCU_CPU_STALL_INFO
1162    bool "Print additional diagnostics on RCU CPU stall"
1163    depends on (TREE_RCU || TREE_PREEMPT_RCU) && DEBUG_KERNEL
1164    default n
1165    help
1166      For each stalled CPU that is aware of the current RCU grace
1167      period, print out additional per-CPU diagnostic information
1168      regarding scheduling-clock ticks, idle state, and,
1169      for RCU_FAST_NO_HZ kernels, idle-entry state.
1170
1171      Say N if you are unsure.
1172
1173      Say Y if you want to enable such diagnostics.
1174
1175config RCU_TRACE
1176    bool "Enable tracing for RCU"
1177    depends on DEBUG_KERNEL
1178    select TRACE_CLOCK
1179    help
1180      This option provides tracing in RCU which presents stats
1181      in debugfs for debugging RCU implementation.
1182
1183      Say Y here if you want to enable RCU tracing
1184      Say N if you are unsure.
1185
1186endmenu # "RCU Debugging"
1187
1188config DEBUG_BLOCK_EXT_DEVT
1189        bool "Force extended block device numbers and spread them"
1190    depends on DEBUG_KERNEL
1191    depends on BLOCK
1192    default n
1193    help
1194      BIG FAT WARNING: ENABLING THIS OPTION MIGHT BREAK BOOTING ON
1195      SOME DISTRIBUTIONS. DO NOT ENABLE THIS UNLESS YOU KNOW WHAT
1196      YOU ARE DOING. Distros, please enable this and fix whatever
1197      is broken.
1198
1199      Conventionally, block device numbers are allocated from
1200      predetermined contiguous area. However, extended block area
1201      may introduce non-contiguous block device numbers. This
1202      option forces most block device numbers to be allocated from
1203      the extended space and spreads them to discover kernel or
1204      userland code paths which assume predetermined contiguous
1205      device number allocation.
1206
1207      Note that turning on this debug option shuffles all the
1208      device numbers for all IDE and SCSI devices including libata
1209      ones, so root partition specified using device number
1210      directly (via rdev or root=MAJ:MIN) won't work anymore.
1211      Textual device names (root=/dev/sdXn) will continue to work.
1212
1213      Say N if you are unsure.
1214
1215config NOTIFIER_ERROR_INJECTION
1216    tristate "Notifier error injection"
1217    depends on DEBUG_KERNEL
1218    select DEBUG_FS
1219    help
1220      This option provides the ability to inject artificial errors to
1221      specified notifier chain callbacks. It is useful to test the error
1222      handling of notifier call chain failures.
1223
1224      Say N if unsure.
1225
1226config CPU_NOTIFIER_ERROR_INJECT
1227    tristate "CPU notifier error injection module"
1228    depends on HOTPLUG_CPU && NOTIFIER_ERROR_INJECTION
1229    help
1230      This option provides a kernel module that can be used to test
1231      the error handling of the cpu notifiers by injecting artificial
1232      errors to CPU notifier chain callbacks. It is controlled through
1233      debugfs interface under /sys/kernel/debug/notifier-error-inject/cpu
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      Example: Inject CPU offline error (-1 == -EPERM)
1239
1240      # cd /sys/kernel/debug/notifier-error-inject/cpu
1241      # echo -1 > actions/CPU_DOWN_PREPARE/error
1242      # echo 0 > /sys/devices/system/cpu/cpu1/online
1243      bash: echo: write error: Operation not permitted
1244
1245      To compile this code as a module, choose M here: the module will
1246      be called cpu-notifier-error-inject.
1247
1248      If unsure, say N.
1249
1250config PM_NOTIFIER_ERROR_INJECT
1251    tristate "PM notifier error injection module"
1252    depends on PM && NOTIFIER_ERROR_INJECTION
1253    default m if PM_DEBUG
1254    help
1255      This option provides the ability to inject artificial errors to
1256      PM notifier chain callbacks. It is controlled through debugfs
1257      interface /sys/kernel/debug/notifier-error-inject/pm
1258
1259      If the notifier call chain should be failed with some events
1260      notified, write the error code to "actions/<notifier event>/error".
1261
1262      Example: Inject PM suspend error (-12 = -ENOMEM)
1263
1264      # cd /sys/kernel/debug/notifier-error-inject/pm/
1265      # echo -12 > actions/PM_SUSPEND_PREPARE/error
1266      # echo mem > /sys/power/state
1267      bash: echo: write error: Cannot allocate memory
1268
1269      To compile this code as a module, choose M here: the module will
1270      be called pm-notifier-error-inject.
1271
1272      If unsure, say N.
1273
1274config OF_RECONFIG_NOTIFIER_ERROR_INJECT
1275    tristate "OF reconfig notifier error injection module"
1276    depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION
1277    help
1278      This option provides the ability to inject artificial errors to
1279      OF reconfig notifier chain callbacks. It is controlled
1280      through debugfs interface under
1281      /sys/kernel/debug/notifier-error-inject/OF-reconfig/
1282
1283      If the notifier call chain should be failed with some events
1284      notified, write the error code to "actions/<notifier event>/error".
1285
1286      To compile this code as a module, choose M here: the module will
1287      be called of-reconfig-notifier-error-inject.
1288
1289      If unsure, say N.
1290
1291config FAULT_INJECTION
1292    bool "Fault-injection framework"
1293    depends on DEBUG_KERNEL
1294    help
1295      Provide fault-injection framework.
1296      For more details, see Documentation/fault-injection/.
1297
1298config FAILSLAB
1299    bool "Fault-injection capability for kmalloc"
1300    depends on FAULT_INJECTION
1301    depends on SLAB || SLUB
1302    help
1303      Provide fault-injection capability for kmalloc.
1304
1305config FAIL_PAGE_ALLOC
1306    bool "Fault-injection capabilitiy for alloc_pages()"
1307    depends on FAULT_INJECTION
1308    help
1309      Provide fault-injection capability for alloc_pages().
1310
1311config FAIL_MAKE_REQUEST
1312    bool "Fault-injection capability for disk IO"
1313    depends on FAULT_INJECTION && BLOCK
1314    help
1315      Provide fault-injection capability for disk IO.
1316
1317config FAIL_IO_TIMEOUT
1318    bool "Fault-injection capability for faking disk interrupts"
1319    depends on FAULT_INJECTION && BLOCK
1320    help
1321      Provide fault-injection capability on end IO handling. This
1322      will make the block layer "forget" an interrupt as configured,
1323      thus exercising the error handling.
1324
1325      Only works with drivers that use the generic timeout handling,
1326      for others it wont do anything.
1327
1328config FAIL_MMC_REQUEST
1329    bool "Fault-injection capability for MMC IO"
1330    select DEBUG_FS
1331    depends on FAULT_INJECTION && MMC
1332    help
1333      Provide fault-injection capability for MMC IO.
1334      This will make the mmc core return data errors. This is
1335      useful to test the error handling in the mmc block device
1336      and to test how the mmc host driver handles retries from
1337      the block device.
1338
1339config FAULT_INJECTION_DEBUG_FS
1340    bool "Debugfs entries for fault-injection capabilities"
1341    depends on FAULT_INJECTION && SYSFS && DEBUG_FS
1342    help
1343      Enable configuration of fault-injection capabilities via debugfs.
1344
1345config FAULT_INJECTION_STACKTRACE_FILTER
1346    bool "stacktrace filter for fault-injection capabilities"
1347    depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT
1348    depends on !X86_64
1349    select STACKTRACE
1350    select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND
1351    help
1352      Provide stacktrace filter for fault-injection capabilities
1353
1354config LATENCYTOP
1355    bool "Latency measuring infrastructure"
1356    depends on HAVE_LATENCYTOP_SUPPORT
1357    depends on DEBUG_KERNEL
1358    depends on STACKTRACE_SUPPORT
1359    depends on PROC_FS
1360    select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND
1361    select KALLSYMS
1362    select KALLSYMS_ALL
1363    select STACKTRACE
1364    select SCHEDSTATS
1365    select SCHED_DEBUG
1366    help
1367      Enable this option if you want to use the LatencyTOP tool
1368      to find out which userspace is blocking on what kernel operations.
1369
1370config ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
1371    bool
1372
1373config DEBUG_STRICT_USER_COPY_CHECKS
1374    bool "Strict user copy size checks"
1375    depends on ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
1376    depends on DEBUG_KERNEL && !TRACE_BRANCH_PROFILING
1377    help
1378      Enabling this option turns a certain set of sanity checks for user
1379      copy operations into compile time failures.
1380
1381      The copy_from_user() etc checks are there to help test if there
1382      are sufficient security checks on the length argument of
1383      the copy operation, by having gcc prove that the argument is
1384      within bounds.
1385
1386      If unsure, say N.
1387
1388source kernel/trace/Kconfig
1389
1390menu "Runtime Testing"
1391
1392config LKDTM
1393    tristate "Linux Kernel Dump Test Tool Module"
1394    depends on DEBUG_FS
1395    depends on BLOCK
1396    default n
1397    help
1398    This module enables testing of the different dumping mechanisms by
1399    inducing system failures at predefined crash points.
1400    If you don't need it: say N
1401    Choose M here to compile this code as a module. The module will be
1402    called lkdtm.
1403
1404    Documentation on how to use the module can be found in
1405    Documentation/fault-injection/provoke-crashes.txt
1406
1407config TEST_LIST_SORT
1408    bool "Linked list sorting test"
1409    depends on DEBUG_KERNEL
1410    help
1411      Enable this to turn on 'list_sort()' function test. This test is
1412      executed only once during system boot, so affects only boot time.
1413
1414      If unsure, say N.
1415
1416config KPROBES_SANITY_TEST
1417    bool "Kprobes sanity tests"
1418    depends on DEBUG_KERNEL
1419    depends on KPROBES
1420    default n
1421    help
1422      This option provides for testing basic kprobes functionality on
1423      boot. A sample kprobe, jprobe and kretprobe are inserted and
1424      verified for functionality.
1425
1426      Say N if you are unsure.
1427
1428config BACKTRACE_SELF_TEST
1429    tristate "Self test for the backtrace code"
1430    depends on DEBUG_KERNEL
1431    default n
1432    help
1433      This option provides a kernel module that can be used to test
1434      the kernel stack backtrace code. This option is not useful
1435      for distributions or general kernels, but only for kernel
1436      developers working on architecture code.
1437
1438      Note that if you want to also test saved backtraces, you will
1439      have to enable STACKTRACE as well.
1440
1441      Say N if you are unsure.
1442
1443config RBTREE_TEST
1444    tristate "Red-Black tree test"
1445    depends on m && DEBUG_KERNEL
1446    help
1447      A benchmark measuring the performance of the rbtree library.
1448      Also includes rbtree invariant checks.
1449
1450config INTERVAL_TREE_TEST
1451    tristate "Interval tree test"
1452    depends on m && DEBUG_KERNEL
1453    help
1454      A benchmark measuring the performance of the interval tree library
1455
1456config ATOMIC64_SELFTEST
1457    bool "Perform an atomic64_t self-test at boot"
1458    help
1459      Enable this option to test the atomic64_t functions at boot.
1460
1461      If unsure, say N.
1462
1463config ASYNC_RAID6_TEST
1464    tristate "Self test for hardware accelerated raid6 recovery"
1465    depends on ASYNC_RAID6_RECOV
1466    select ASYNC_MEMCPY
1467    ---help---
1468      This is a one-shot self test that permutes through the
1469      recovery of all the possible two disk failure scenarios for a
1470      N-disk array. Recovery is performed with the asynchronous
1471      raid6 recovery routines, and will optionally use an offload
1472      engine if one is available.
1473
1474      If unsure, say N.
1475
1476config TEST_STRING_HELPERS
1477    tristate "Test functions located in the string_helpers module at runtime"
1478
1479config TEST_KSTRTOX
1480    tristate "Test kstrto*() family of functions at runtime"
1481
1482endmenu # runtime tests
1483
1484config PROVIDE_OHCI1394_DMA_INIT
1485    bool "Remote debugging over FireWire early on boot"
1486    depends on PCI && X86
1487    help
1488      If you want to debug problems which hang or crash the kernel early
1489      on boot and the crashing machine has a FireWire port, you can use
1490      this feature to remotely access the memory of the crashed machine
1491      over FireWire. This employs remote DMA as part of the OHCI1394
1492      specification which is now the standard for FireWire controllers.
1493
1494      With remote DMA, you can monitor the printk buffer remotely using
1495      firescope and access all memory below 4GB using fireproxy from gdb.
1496      Even controlling a kernel debugger is possible using remote DMA.
1497
1498      Usage:
1499
1500      If ohci1394_dma=early is used as boot parameter, it will initialize
1501      all OHCI1394 controllers which are found in the PCI config space.
1502
1503      As all changes to the FireWire bus such as enabling and disabling
1504      devices cause a bus reset and thereby disable remote DMA for all
1505      devices, be sure to have the cable plugged and FireWire enabled on
1506      the debugging host before booting the debug target for debugging.
1507
1508      This code (~1k) is freed after boot. By then, the firewire stack
1509      in charge of the OHCI-1394 controllers should be used instead.
1510
1511      See Documentation/debugging-via-ohci1394.txt for more information.
1512
1513config FIREWIRE_OHCI_REMOTE_DMA
1514    bool "Remote debugging over FireWire with firewire-ohci"
1515    depends on FIREWIRE_OHCI
1516    help
1517      This option lets you use the FireWire bus for remote debugging
1518      with help of the firewire-ohci driver. It enables unfiltered
1519      remote DMA in firewire-ohci.
1520      See Documentation/debugging-via-ohci1394.txt for more information.
1521
1522      If unsure, say N.
1523
1524config BUILD_DOCSRC
1525    bool "Build targets in Documentation/ tree"
1526    depends on HEADERS_CHECK
1527    help
1528      This option attempts to build objects from the source files in the
1529      kernel Documentation/ tree.
1530
1531      Say N if you are unsure.
1532
1533config DMA_API_DEBUG
1534    bool "Enable debugging of DMA-API usage"
1535    depends on HAVE_DMA_API_DEBUG
1536    help
1537      Enable this option to debug the use of the DMA API by device drivers.
1538      With this option you will be able to detect common bugs in device
1539      drivers like double-freeing of DMA mappings or freeing mappings that
1540      were never allocated.
1541      This option causes a performance degredation. Use only if you want
1542      to debug device drivers. If unsure, say N.
1543
1544source "samples/Kconfig"
1545
1546source "lib/Kconfig.kgdb"
1547
1548

Archive Download this file



interactive