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
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 && !ARC
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 DEBUG_KOBJECT_RELEASE
985    bool "kobject release debugging"
986    depends on DEBUG_OBJECTS_TIMERS
987    help
988      kobjects are reference counted objects. This means that their
989      last reference count put is not predictable, and the kobject can
990      live on past the point at which a driver decides to drop it's
991      initial reference to the kobject gained on allocation. An
992      example of this would be a struct device which has just been
993      unregistered.
994
995      However, some buggy drivers assume that after such an operation,
996      the memory backing the kobject can be immediately freed. This
997      goes completely against the principles of a refcounted object.
998
999      If you say Y here, the kernel will delay the release of kobjects
1000      on the last reference count to improve the visibility of this
1001      kind of kobject release bug.
1002
1003config HAVE_DEBUG_BUGVERBOSE
1004    bool
1005
1006config DEBUG_BUGVERBOSE
1007    bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
1008    depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
1009    default y
1010    help
1011      Say Y here to make BUG() panics output the file name and line number
1012      of the BUG call as well as the EIP and oops trace. This aids
1013      debugging but costs about 70-100K of memory.
1014
1015config DEBUG_WRITECOUNT
1016    bool "Debug filesystem writers count"
1017    depends on DEBUG_KERNEL
1018    help
1019      Enable this to catch wrong use of the writers count in struct
1020      vfsmount. This will increase the size of each file struct by
1021      32 bits.
1022
1023      If unsure, say N.
1024
1025config DEBUG_LIST
1026    bool "Debug linked list manipulation"
1027    depends on DEBUG_KERNEL
1028    help
1029      Enable this to turn on extended checks in the linked-list
1030      walking routines.
1031
1032      If unsure, say N.
1033
1034config DEBUG_SG
1035    bool "Debug SG table operations"
1036    depends on DEBUG_KERNEL
1037    help
1038      Enable this to turn on checks on scatter-gather tables. This can
1039      help find problems with drivers that do not properly initialize
1040      their sg tables.
1041
1042      If unsure, say N.
1043
1044config DEBUG_NOTIFIERS
1045    bool "Debug notifier call chains"
1046    depends on DEBUG_KERNEL
1047    help
1048      Enable this to turn on sanity checking for notifier call chains.
1049      This is most useful for kernel developers to make sure that
1050      modules properly unregister themselves from notifier chains.
1051      This is a relatively cheap check but if you care about maximum
1052      performance, say N.
1053
1054config DEBUG_CREDENTIALS
1055    bool "Debug credential management"
1056    depends on DEBUG_KERNEL
1057    help
1058      Enable this to turn on some debug checking for credential
1059      management. The additional code keeps track of the number of
1060      pointers from task_structs to any given cred struct, and checks to
1061      see that this number never exceeds the usage count of the cred
1062      struct.
1063
1064      Furthermore, if SELinux is enabled, this also checks that the
1065      security pointer in the cred struct is never seen to be invalid.
1066
1067      If unsure, say N.
1068
1069menu "RCU Debugging"
1070
1071config PROVE_RCU
1072    bool "RCU debugging: prove RCU correctness"
1073    depends on PROVE_LOCKING
1074    default n
1075    help
1076     This feature enables lockdep extensions that check for correct
1077     use of RCU APIs. This is currently under development. Say Y
1078     if you want to debug RCU usage or help work on the PROVE_RCU
1079     feature.
1080
1081     Say N if you are unsure.
1082
1083config PROVE_RCU_REPEATEDLY
1084    bool "RCU debugging: don't disable PROVE_RCU on first splat"
1085    depends on PROVE_RCU
1086    default n
1087    help
1088     By itself, PROVE_RCU will disable checking upon issuing the
1089     first warning (or "splat"). This feature prevents such
1090     disabling, allowing multiple RCU-lockdep warnings to be printed
1091     on a single reboot.
1092
1093     Say Y to allow multiple RCU-lockdep warnings per boot.
1094
1095     Say N if you are unsure.
1096
1097config PROVE_RCU_DELAY
1098    bool "RCU debugging: preemptible RCU race provocation"
1099    depends on DEBUG_KERNEL && PREEMPT_RCU
1100    default n
1101    help
1102     There is a class of races that involve an unlikely preemption
1103     of __rcu_read_unlock() just after ->rcu_read_lock_nesting has
1104     been set to INT_MIN. This feature inserts a delay at that
1105     point to increase the probability of these races.
1106
1107     Say Y to increase probability of preemption of __rcu_read_unlock().
1108
1109     Say N if you are unsure.
1110
1111config SPARSE_RCU_POINTER
1112    bool "RCU debugging: sparse-based checks for pointer usage"
1113    default n
1114    help
1115     This feature enables the __rcu sparse annotation for
1116     RCU-protected pointers. This annotation will cause sparse
1117     to flag any non-RCU used of annotated pointers. This can be
1118     helpful when debugging RCU usage. Please note that this feature
1119     is not intended to enforce code cleanliness; it is instead merely
1120     a debugging aid.
1121
1122     Say Y to make sparse flag questionable use of RCU-protected pointers
1123
1124     Say N if you are unsure.
1125
1126config RCU_TORTURE_TEST
1127    tristate "torture tests for RCU"
1128    depends on DEBUG_KERNEL
1129    default n
1130    help
1131      This option provides a kernel module that runs torture tests
1132      on the RCU infrastructure. The kernel module may be built
1133      after the fact on the running kernel to be tested, if desired.
1134
1135      Say Y here if you want RCU torture tests to be built into
1136      the kernel.
1137      Say M if you want the RCU torture tests to build as a module.
1138      Say N if you are unsure.
1139
1140config RCU_TORTURE_TEST_RUNNABLE
1141    bool "torture tests for RCU runnable by default"
1142    depends on RCU_TORTURE_TEST = y
1143    default n
1144    help
1145      This option provides a way to build the RCU torture tests
1146      directly into the kernel without them starting up at boot
1147      time. You can use /proc/sys/kernel/rcutorture_runnable
1148      to manually override this setting. This /proc file is
1149      available only when the RCU torture tests have been built
1150      into the kernel.
1151
1152      Say Y here if you want the RCU torture tests to start during
1153      boot (you probably don't).
1154      Say N here if you want the RCU torture tests to start only
1155      after being manually enabled via /proc.
1156
1157config RCU_CPU_STALL_TIMEOUT
1158    int "RCU CPU stall timeout in seconds"
1159    depends on RCU_STALL_COMMON
1160    range 3 300
1161    default 21
1162    help
1163      If a given RCU grace period extends more than the specified
1164      number of seconds, a CPU stall warning is printed. If the
1165      RCU grace period persists, additional CPU stall warnings are
1166      printed at more widely spaced intervals.
1167
1168config RCU_CPU_STALL_VERBOSE
1169    bool "Print additional per-task information for RCU_CPU_STALL_DETECTOR"
1170    depends on TREE_PREEMPT_RCU
1171    default y
1172    help
1173      This option causes RCU to printk detailed per-task information
1174      for any tasks that are stalling the current RCU grace period.
1175
1176      Say N if you are unsure.
1177
1178      Say Y if you want to enable such checks.
1179
1180config RCU_CPU_STALL_INFO
1181    bool "Print additional diagnostics on RCU CPU stall"
1182    depends on (TREE_RCU || TREE_PREEMPT_RCU) && DEBUG_KERNEL
1183    default n
1184    help
1185      For each stalled CPU that is aware of the current RCU grace
1186      period, print out additional per-CPU diagnostic information
1187      regarding scheduling-clock ticks, idle state, and,
1188      for RCU_FAST_NO_HZ kernels, idle-entry state.
1189
1190      Say N if you are unsure.
1191
1192      Say Y if you want to enable such diagnostics.
1193
1194config RCU_TRACE
1195    bool "Enable tracing for RCU"
1196    depends on DEBUG_KERNEL
1197    select TRACE_CLOCK
1198    help
1199      This option provides tracing in RCU which presents stats
1200      in debugfs for debugging RCU implementation.
1201
1202      Say Y here if you want to enable RCU tracing
1203      Say N if you are unsure.
1204
1205endmenu # "RCU Debugging"
1206
1207config DEBUG_BLOCK_EXT_DEVT
1208        bool "Force extended block device numbers and spread them"
1209    depends on DEBUG_KERNEL
1210    depends on BLOCK
1211    default n
1212    help
1213      BIG FAT WARNING: ENABLING THIS OPTION MIGHT BREAK BOOTING ON
1214      SOME DISTRIBUTIONS. DO NOT ENABLE THIS UNLESS YOU KNOW WHAT
1215      YOU ARE DOING. Distros, please enable this and fix whatever
1216      is broken.
1217
1218      Conventionally, block device numbers are allocated from
1219      predetermined contiguous area. However, extended block area
1220      may introduce non-contiguous block device numbers. This
1221      option forces most block device numbers to be allocated from
1222      the extended space and spreads them to discover kernel or
1223      userland code paths which assume predetermined contiguous
1224      device number allocation.
1225
1226      Note that turning on this debug option shuffles all the
1227      device numbers for all IDE and SCSI devices including libata
1228      ones, so root partition specified using device number
1229      directly (via rdev or root=MAJ:MIN) won't work anymore.
1230      Textual device names (root=/dev/sdXn) will continue to work.
1231
1232      Say N if you are unsure.
1233
1234config NOTIFIER_ERROR_INJECTION
1235    tristate "Notifier error injection"
1236    depends on DEBUG_KERNEL
1237    select DEBUG_FS
1238    help
1239      This option provides the ability to inject artificial errors to
1240      specified notifier chain callbacks. It is useful to test the error
1241      handling of notifier call chain failures.
1242
1243      Say N if unsure.
1244
1245config CPU_NOTIFIER_ERROR_INJECT
1246    tristate "CPU notifier error injection module"
1247    depends on HOTPLUG_CPU && NOTIFIER_ERROR_INJECTION
1248    help
1249      This option provides a kernel module that can be used to test
1250      the error handling of the cpu notifiers by injecting artificial
1251      errors to CPU notifier chain callbacks. It is controlled through
1252      debugfs interface under /sys/kernel/debug/notifier-error-inject/cpu
1253
1254      If the notifier call chain should be failed with some events
1255      notified, write the error code to "actions/<notifier event>/error".
1256
1257      Example: Inject CPU offline error (-1 == -EPERM)
1258
1259      # cd /sys/kernel/debug/notifier-error-inject/cpu
1260      # echo -1 > actions/CPU_DOWN_PREPARE/error
1261      # echo 0 > /sys/devices/system/cpu/cpu1/online
1262      bash: echo: write error: Operation not permitted
1263
1264      To compile this code as a module, choose M here: the module will
1265      be called cpu-notifier-error-inject.
1266
1267      If unsure, say N.
1268
1269config PM_NOTIFIER_ERROR_INJECT
1270    tristate "PM notifier error injection module"
1271    depends on PM && NOTIFIER_ERROR_INJECTION
1272    default m if PM_DEBUG
1273    help
1274      This option provides the ability to inject artificial errors to
1275      PM notifier chain callbacks. It is controlled through debugfs
1276      interface /sys/kernel/debug/notifier-error-inject/pm
1277
1278      If the notifier call chain should be failed with some events
1279      notified, write the error code to "actions/<notifier event>/error".
1280
1281      Example: Inject PM suspend error (-12 = -ENOMEM)
1282
1283      # cd /sys/kernel/debug/notifier-error-inject/pm/
1284      # echo -12 > actions/PM_SUSPEND_PREPARE/error
1285      # echo mem > /sys/power/state
1286      bash: echo: write error: Cannot allocate memory
1287
1288      To compile this code as a module, choose M here: the module will
1289      be called pm-notifier-error-inject.
1290
1291      If unsure, say N.
1292
1293config OF_RECONFIG_NOTIFIER_ERROR_INJECT
1294    tristate "OF reconfig notifier error injection module"
1295    depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION
1296    help
1297      This option provides the ability to inject artificial errors to
1298      OF reconfig notifier chain callbacks. It is controlled
1299      through debugfs interface under
1300      /sys/kernel/debug/notifier-error-inject/OF-reconfig/
1301
1302      If the notifier call chain should be failed with some events
1303      notified, write the error code to "actions/<notifier event>/error".
1304
1305      To compile this code as a module, choose M here: the module will
1306      be called of-reconfig-notifier-error-inject.
1307
1308      If unsure, say N.
1309
1310config FAULT_INJECTION
1311    bool "Fault-injection framework"
1312    depends on DEBUG_KERNEL
1313    help
1314      Provide fault-injection framework.
1315      For more details, see Documentation/fault-injection/.
1316
1317config FAILSLAB
1318    bool "Fault-injection capability for kmalloc"
1319    depends on FAULT_INJECTION
1320    depends on SLAB || SLUB
1321    help
1322      Provide fault-injection capability for kmalloc.
1323
1324config FAIL_PAGE_ALLOC
1325    bool "Fault-injection capabilitiy for alloc_pages()"
1326    depends on FAULT_INJECTION
1327    help
1328      Provide fault-injection capability for alloc_pages().
1329
1330config FAIL_MAKE_REQUEST
1331    bool "Fault-injection capability for disk IO"
1332    depends on FAULT_INJECTION && BLOCK
1333    help
1334      Provide fault-injection capability for disk IO.
1335
1336config FAIL_IO_TIMEOUT
1337    bool "Fault-injection capability for faking disk interrupts"
1338    depends on FAULT_INJECTION && BLOCK
1339    help
1340      Provide fault-injection capability on end IO handling. This
1341      will make the block layer "forget" an interrupt as configured,
1342      thus exercising the error handling.
1343
1344      Only works with drivers that use the generic timeout handling,
1345      for others it wont do anything.
1346
1347config FAIL_MMC_REQUEST
1348    bool "Fault-injection capability for MMC IO"
1349    select DEBUG_FS
1350    depends on FAULT_INJECTION && MMC
1351    help
1352      Provide fault-injection capability for MMC IO.
1353      This will make the mmc core return data errors. This is
1354      useful to test the error handling in the mmc block device
1355      and to test how the mmc host driver handles retries from
1356      the block device.
1357
1358config FAULT_INJECTION_DEBUG_FS
1359    bool "Debugfs entries for fault-injection capabilities"
1360    depends on FAULT_INJECTION && SYSFS && DEBUG_FS
1361    help
1362      Enable configuration of fault-injection capabilities via debugfs.
1363
1364config FAULT_INJECTION_STACKTRACE_FILTER
1365    bool "stacktrace filter for fault-injection capabilities"
1366    depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT
1367    depends on !X86_64
1368    select STACKTRACE
1369    select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND && !ARC
1370    help
1371      Provide stacktrace filter for fault-injection capabilities
1372
1373config LATENCYTOP
1374    bool "Latency measuring infrastructure"
1375    depends on HAVE_LATENCYTOP_SUPPORT
1376    depends on DEBUG_KERNEL
1377    depends on STACKTRACE_SUPPORT
1378    depends on PROC_FS
1379    select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND && !ARC
1380    select KALLSYMS
1381    select KALLSYMS_ALL
1382    select STACKTRACE
1383    select SCHEDSTATS
1384    select SCHED_DEBUG
1385    help
1386      Enable this option if you want to use the LatencyTOP tool
1387      to find out which userspace is blocking on what kernel operations.
1388
1389config ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
1390    bool
1391
1392config DEBUG_STRICT_USER_COPY_CHECKS
1393    bool "Strict user copy size checks"
1394    depends on ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
1395    depends on DEBUG_KERNEL && !TRACE_BRANCH_PROFILING
1396    help
1397      Enabling this option turns a certain set of sanity checks for user
1398      copy operations into compile time failures.
1399
1400      The copy_from_user() etc checks are there to help test if there
1401      are sufficient security checks on the length argument of
1402      the copy operation, by having gcc prove that the argument is
1403      within bounds.
1404
1405      If unsure, say N.
1406
1407source kernel/trace/Kconfig
1408
1409menu "Runtime Testing"
1410
1411config LKDTM
1412    tristate "Linux Kernel Dump Test Tool Module"
1413    depends on DEBUG_FS
1414    depends on BLOCK
1415    default n
1416    help
1417    This module enables testing of the different dumping mechanisms by
1418    inducing system failures at predefined crash points.
1419    If you don't need it: say N
1420    Choose M here to compile this code as a module. The module will be
1421    called lkdtm.
1422
1423    Documentation on how to use the module can be found in
1424    Documentation/fault-injection/provoke-crashes.txt
1425
1426config TEST_LIST_SORT
1427    bool "Linked list sorting test"
1428    depends on DEBUG_KERNEL
1429    help
1430      Enable this to turn on 'list_sort()' function test. This test is
1431      executed only once during system boot, so affects only boot time.
1432
1433      If unsure, say N.
1434
1435config KPROBES_SANITY_TEST
1436    bool "Kprobes sanity tests"
1437    depends on DEBUG_KERNEL
1438    depends on KPROBES
1439    default n
1440    help
1441      This option provides for testing basic kprobes functionality on
1442      boot. A sample kprobe, jprobe and kretprobe are inserted and
1443      verified for functionality.
1444
1445      Say N if you are unsure.
1446
1447config BACKTRACE_SELF_TEST
1448    tristate "Self test for the backtrace code"
1449    depends on DEBUG_KERNEL
1450    default n
1451    help
1452      This option provides a kernel module that can be used to test
1453      the kernel stack backtrace code. This option is not useful
1454      for distributions or general kernels, but only for kernel
1455      developers working on architecture code.
1456
1457      Note that if you want to also test saved backtraces, you will
1458      have to enable STACKTRACE as well.
1459
1460      Say N if you are unsure.
1461
1462config RBTREE_TEST
1463    tristate "Red-Black tree test"
1464    depends on DEBUG_KERNEL
1465    help
1466      A benchmark measuring the performance of the rbtree library.
1467      Also includes rbtree invariant checks.
1468
1469config INTERVAL_TREE_TEST
1470    tristate "Interval tree test"
1471    depends on m && DEBUG_KERNEL
1472    help
1473      A benchmark measuring the performance of the interval tree library
1474
1475config ATOMIC64_SELFTEST
1476    bool "Perform an atomic64_t self-test at boot"
1477    help
1478      Enable this option to test the atomic64_t functions at boot.
1479
1480      If unsure, say N.
1481
1482config ASYNC_RAID6_TEST
1483    tristate "Self test for hardware accelerated raid6 recovery"
1484    depends on ASYNC_RAID6_RECOV
1485    select ASYNC_MEMCPY
1486    ---help---
1487      This is a one-shot self test that permutes through the
1488      recovery of all the possible two disk failure scenarios for a
1489      N-disk array. Recovery is performed with the asynchronous
1490      raid6 recovery routines, and will optionally use an offload
1491      engine if one is available.
1492
1493      If unsure, say N.
1494
1495config TEST_STRING_HELPERS
1496    tristate "Test functions located in the string_helpers module at runtime"
1497
1498config TEST_KSTRTOX
1499    tristate "Test kstrto*() family of functions at runtime"
1500
1501endmenu # runtime tests
1502
1503config PROVIDE_OHCI1394_DMA_INIT
1504    bool "Remote debugging over FireWire early on boot"
1505    depends on PCI && X86
1506    help
1507      If you want to debug problems which hang or crash the kernel early
1508      on boot and the crashing machine has a FireWire port, you can use
1509      this feature to remotely access the memory of the crashed machine
1510      over FireWire. This employs remote DMA as part of the OHCI1394
1511      specification which is now the standard for FireWire controllers.
1512
1513      With remote DMA, you can monitor the printk buffer remotely using
1514      firescope and access all memory below 4GB using fireproxy from gdb.
1515      Even controlling a kernel debugger is possible using remote DMA.
1516
1517      Usage:
1518
1519      If ohci1394_dma=early is used as boot parameter, it will initialize
1520      all OHCI1394 controllers which are found in the PCI config space.
1521
1522      As all changes to the FireWire bus such as enabling and disabling
1523      devices cause a bus reset and thereby disable remote DMA for all
1524      devices, be sure to have the cable plugged and FireWire enabled on
1525      the debugging host before booting the debug target for debugging.
1526
1527      This code (~1k) is freed after boot. By then, the firewire stack
1528      in charge of the OHCI-1394 controllers should be used instead.
1529
1530      See Documentation/debugging-via-ohci1394.txt for more information.
1531
1532config FIREWIRE_OHCI_REMOTE_DMA
1533    bool "Remote debugging over FireWire with firewire-ohci"
1534    depends on FIREWIRE_OHCI
1535    help
1536      This option lets you use the FireWire bus for remote debugging
1537      with help of the firewire-ohci driver. It enables unfiltered
1538      remote DMA in firewire-ohci.
1539      See Documentation/debugging-via-ohci1394.txt for more information.
1540
1541      If unsure, say N.
1542
1543config BUILD_DOCSRC
1544    bool "Build targets in Documentation/ tree"
1545    depends on HEADERS_CHECK
1546    help
1547      This option attempts to build objects from the source files in the
1548      kernel Documentation/ tree.
1549
1550      Say N if you are unsure.
1551
1552config DMA_API_DEBUG
1553    bool "Enable debugging of DMA-API usage"
1554    depends on HAVE_DMA_API_DEBUG
1555    help
1556      Enable this option to debug the use of the DMA API by device drivers.
1557      With this option you will be able to detect common bugs in device
1558      drivers like double-freeing of DMA mappings or freeing mappings that
1559      were never allocated.
1560      This option causes a performance degredation. Use only if you want
1561      to debug device drivers. If unsure, say N.
1562
1563source "samples/Kconfig"
1564
1565source "lib/Kconfig.kgdb"
1566
1567

Archive Download this file



interactive