1 2config 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 17config 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 28config 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 36config 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 44config 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 55config 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 69config 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 77config 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 93config 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 105config 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 119config 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 150config 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 156config 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 165config 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 189config HARDLOCKUP_DETECTOR 190 def_bool LOCKUP_DETECTOR && PERF_EVENTS && HAVE_PERF_EVENTS_NMI && \ 191 !HAVE_NMI_WATCHDOG 192 193config 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 204config 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 211config 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 228config 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 235config 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 250config 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 266config 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 282config 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 289config 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 298config 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 310config 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 324config 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 332config 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 338config 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 347config 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 355config 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 363config 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 369config 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 377config 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 385config 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 393config DEBUG_SLAB_LEAK 394 bool "Memory leak debugging" 395 depends on DEBUG_SLAB 396 397config 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 410config 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 423config 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 448config 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 460config 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 468config 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 475config 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 485config 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 492config DEBUG_PI_LIST 493 bool 494 default y 495 depends on DEBUG_RT_MUTEXES 496 497config 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 503config 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 513config 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 520config 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 534config 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 577config 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 589config 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 603config 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 618config 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 626config 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 647config 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 655config TRACE_IRQFLAGS 656 bool 657 help 658 Enables hooks to interrupt enabling and disabling for 659 either tracing or lock debugging. 660 661config 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 671config 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 682config STACKTRACE 683 bool 684 depends on STACKTRACE_SUPPORT 685 686config 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 695config 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 702config 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 709config 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 720config 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 733config 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 746config 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 755config 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 764config 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 771config 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 781config 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 793config 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 802config 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 811config 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 821config 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 831config 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# 851config ARCH_WANT_FRAME_POINTERS 852 bool 853 help 854 855config 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 867config 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 885config 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 899config 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 916config 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 927config 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 939config 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 953config 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 963config 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 975config 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 990config 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 1017config 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 1032config 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 1043config 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 1058config 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 1070config 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 1077config 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 1084config 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 1090config 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 1096config 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 1107config 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 1118config 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 1124config 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 1133config 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 1149source mm/Kconfig.debug 1150source kernel/trace/Kconfig 1151 1152config 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 1181config 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 1192config 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 1201config 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 1270config 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 1281config 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 1288config 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 1301source "samples/Kconfig" 1302 1303source "lib/Kconfig.kgdb" 1304 1305source "lib/Kconfig.kmemcheck" 1306 1307config TEST_KSTRTOX 1308 tristate "Test kstrto*() family of functions at runtime" 1309