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