1# SPDX-License-Identifier: GPL-2.0-only 2# 3# Architectures that offer an FUNCTION_TRACER implementation should 4# select HAVE_FUNCTION_TRACER: 5# 6 7config USER_STACKTRACE_SUPPORT 8 bool 9 10config NOP_TRACER 11 bool 12 13config HAVE_RETHOOK 14 bool 15 16config RETHOOK 17 bool 18 depends on HAVE_RETHOOK 19 help 20 Enable generic return hooking feature. This is an internal 21 API, which will be used by other function-entry hooking 22 features like fprobe and kprobes. 23 24config HAVE_FUNCTION_TRACER 25 bool 26 help 27 See Documentation/trace/ftrace-design.rst 28 29config HAVE_FUNCTION_GRAPH_TRACER 30 bool 31 help 32 See Documentation/trace/ftrace-design.rst 33 34config HAVE_DYNAMIC_FTRACE 35 bool 36 help 37 See Documentation/trace/ftrace-design.rst 38 39config HAVE_DYNAMIC_FTRACE_WITH_REGS 40 bool 41 42config HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS 43 bool 44 45config HAVE_DYNAMIC_FTRACE_WITH_ARGS 46 bool 47 help 48 If this is set, then arguments and stack can be found from 49 the pt_regs passed into the function callback regs parameter 50 by default, even without setting the REGS flag in the ftrace_ops. 51 This allows for use of regs_get_kernel_argument() and 52 kernel_stack_pointer(). 53 54config HAVE_DYNAMIC_FTRACE_NO_PATCHABLE 55 bool 56 help 57 If the architecture generates __patchable_function_entries sections 58 but does not want them included in the ftrace locations. 59 60config HAVE_FTRACE_MCOUNT_RECORD 61 bool 62 help 63 See Documentation/trace/ftrace-design.rst 64 65config HAVE_SYSCALL_TRACEPOINTS 66 bool 67 help 68 See Documentation/trace/ftrace-design.rst 69 70config HAVE_FENTRY 71 bool 72 help 73 Arch supports the gcc options -pg with -mfentry 74 75config HAVE_NOP_MCOUNT 76 bool 77 help 78 Arch supports the gcc options -pg with -mrecord-mcount and -nop-mcount 79 80config HAVE_OBJTOOL_MCOUNT 81 bool 82 help 83 Arch supports objtool --mcount 84 85config HAVE_OBJTOOL_NOP_MCOUNT 86 bool 87 help 88 Arch supports the objtool options --mcount with --mnop. 89 An architecture can select this if it wants to enable nop'ing 90 of ftrace locations. 91 92config HAVE_C_RECORDMCOUNT 93 bool 94 help 95 C version of recordmcount available? 96 97config HAVE_BUILDTIME_MCOUNT_SORT 98 bool 99 help 100 An architecture selects this if it sorts the mcount_loc section 101 at build time. 102 103config BUILDTIME_MCOUNT_SORT 104 bool 105 default y 106 depends on HAVE_BUILDTIME_MCOUNT_SORT && DYNAMIC_FTRACE 107 help 108 Sort the mcount_loc section at build time. 109 110config TRACER_MAX_TRACE 111 bool 112 113config TRACE_CLOCK 114 bool 115 116config RING_BUFFER 117 bool 118 select TRACE_CLOCK 119 select IRQ_WORK 120 121config EVENT_TRACING 122 select CONTEXT_SWITCH_TRACER 123 select GLOB 124 bool 125 126config CONTEXT_SWITCH_TRACER 127 bool 128 129config RING_BUFFER_ALLOW_SWAP 130 bool 131 help 132 Allow the use of ring_buffer_swap_cpu. 133 Adds a very slight overhead to tracing when enabled. 134 135config PREEMPTIRQ_TRACEPOINTS 136 bool 137 depends on TRACE_PREEMPT_TOGGLE || TRACE_IRQFLAGS 138 select TRACING 139 default y 140 help 141 Create preempt/irq toggle tracepoints if needed, so that other parts 142 of the kernel can use them to generate or add hooks to them. 143 144# All tracer options should select GENERIC_TRACER. For those options that are 145# enabled by all tracers (context switch and event tracer) they select TRACING. 146# This allows those options to appear when no other tracer is selected. But the 147# options do not appear when something else selects it. We need the two options 148# GENERIC_TRACER and TRACING to avoid circular dependencies to accomplish the 149# hiding of the automatic options. 150 151config TRACING 152 bool 153 select RING_BUFFER 154 select STACKTRACE if STACKTRACE_SUPPORT 155 select TRACEPOINTS 156 select NOP_TRACER 157 select BINARY_PRINTF 158 select EVENT_TRACING 159 select TRACE_CLOCK 160 select TASKS_RCU if PREEMPTION 161 162config GENERIC_TRACER 163 bool 164 select TRACING 165 166# 167# Minimum requirements an architecture has to meet for us to 168# be able to offer generic tracing facilities: 169# 170config TRACING_SUPPORT 171 bool 172 depends on TRACE_IRQFLAGS_SUPPORT 173 depends on STACKTRACE_SUPPORT 174 default y 175 176menuconfig FTRACE 177 bool "Tracers" 178 depends on TRACING_SUPPORT 179 default y if DEBUG_KERNEL 180 help 181 Enable the kernel tracing infrastructure. 182 183if FTRACE 184 185config BOOTTIME_TRACING 186 bool "Boot-time Tracing support" 187 depends on TRACING 188 select BOOT_CONFIG 189 help 190 Enable developer to setup ftrace subsystem via supplemental 191 kernel cmdline at boot time for debugging (tracing) driver 192 initialization and boot process. 193 194config FUNCTION_TRACER 195 bool "Kernel Function Tracer" 196 depends on HAVE_FUNCTION_TRACER 197 select KALLSYMS 198 select GENERIC_TRACER 199 select CONTEXT_SWITCH_TRACER 200 select GLOB 201 select TASKS_RCU if PREEMPTION 202 select TASKS_RUDE_RCU 203 help 204 Enable the kernel to trace every kernel function. This is done 205 by using a compiler feature to insert a small, 5-byte No-Operation 206 instruction at the beginning of every kernel function, which NOP 207 sequence is then dynamically patched into a tracer call when 208 tracing is enabled by the administrator. If it's runtime disabled 209 (the bootup default), then the overhead of the instructions is very 210 small and not measurable even in micro-benchmarks (at least on 211 x86, but may have impact on other architectures). 212 213config FUNCTION_GRAPH_TRACER 214 bool "Kernel Function Graph Tracer" 215 depends on HAVE_FUNCTION_GRAPH_TRACER 216 depends on FUNCTION_TRACER 217 depends on !X86_32 || !CC_OPTIMIZE_FOR_SIZE 218 default y 219 help 220 Enable the kernel to trace a function at both its return 221 and its entry. 222 Its first purpose is to trace the duration of functions and 223 draw a call graph for each thread with some information like 224 the return value. This is done by setting the current return 225 address on the current task structure into a stack of calls. 226 227config DYNAMIC_FTRACE 228 bool "enable/disable function tracing dynamically" 229 depends on FUNCTION_TRACER 230 depends on HAVE_DYNAMIC_FTRACE 231 default y 232 help 233 This option will modify all the calls to function tracing 234 dynamically (will patch them out of the binary image and 235 replace them with a No-Op instruction) on boot up. During 236 compile time, a table is made of all the locations that ftrace 237 can function trace, and this table is linked into the kernel 238 image. When this is enabled, functions can be individually 239 enabled, and the functions not enabled will not affect 240 performance of the system. 241 242 See the files in /sys/kernel/debug/tracing: 243 available_filter_functions 244 set_ftrace_filter 245 set_ftrace_notrace 246 247 This way a CONFIG_FUNCTION_TRACER kernel is slightly larger, but 248 otherwise has native performance as long as no tracing is active. 249 250config DYNAMIC_FTRACE_WITH_REGS 251 def_bool y 252 depends on DYNAMIC_FTRACE 253 depends on HAVE_DYNAMIC_FTRACE_WITH_REGS 254 255config DYNAMIC_FTRACE_WITH_DIRECT_CALLS 256 def_bool y 257 depends on DYNAMIC_FTRACE_WITH_REGS 258 depends on HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS 259 260config DYNAMIC_FTRACE_WITH_ARGS 261 def_bool y 262 depends on DYNAMIC_FTRACE 263 depends on HAVE_DYNAMIC_FTRACE_WITH_ARGS 264 265config FPROBE 266 bool "Kernel Function Probe (fprobe)" 267 depends on FUNCTION_TRACER 268 depends on DYNAMIC_FTRACE_WITH_REGS 269 depends on HAVE_RETHOOK 270 select RETHOOK 271 default n 272 help 273 This option enables kernel function probe (fprobe) based on ftrace. 274 The fprobe is similar to kprobes, but probes only for kernel function 275 entries and exits. This also can probe multiple functions by one 276 fprobe. 277 278 If unsure, say N. 279 280config FUNCTION_PROFILER 281 bool "Kernel function profiler" 282 depends on FUNCTION_TRACER 283 default n 284 help 285 This option enables the kernel function profiler. A file is created 286 in debugfs called function_profile_enabled which defaults to zero. 287 When a 1 is echoed into this file profiling begins, and when a 288 zero is entered, profiling stops. A "functions" file is created in 289 the trace_stat directory; this file shows the list of functions that 290 have been hit and their counters. 291 292 If in doubt, say N. 293 294config STACK_TRACER 295 bool "Trace max stack" 296 depends on HAVE_FUNCTION_TRACER 297 select FUNCTION_TRACER 298 select STACKTRACE 299 select KALLSYMS 300 help 301 This special tracer records the maximum stack footprint of the 302 kernel and displays it in /sys/kernel/debug/tracing/stack_trace. 303 304 This tracer works by hooking into every function call that the 305 kernel executes, and keeping a maximum stack depth value and 306 stack-trace saved. If this is configured with DYNAMIC_FTRACE 307 then it will not have any overhead while the stack tracer 308 is disabled. 309 310 To enable the stack tracer on bootup, pass in 'stacktrace' 311 on the kernel command line. 312 313 The stack tracer can also be enabled or disabled via the 314 sysctl kernel.stack_tracer_enabled 315 316 Say N if unsure. 317 318config TRACE_PREEMPT_TOGGLE 319 bool 320 help 321 Enables hooks which will be called when preemption is first disabled, 322 and last enabled. 323 324config IRQSOFF_TRACER 325 bool "Interrupts-off Latency Tracer" 326 default n 327 depends on TRACE_IRQFLAGS_SUPPORT 328 select TRACE_IRQFLAGS 329 select GENERIC_TRACER 330 select TRACER_MAX_TRACE 331 select RING_BUFFER_ALLOW_SWAP 332 select TRACER_SNAPSHOT 333 select TRACER_SNAPSHOT_PER_CPU_SWAP 334 help 335 This option measures the time spent in irqs-off critical 336 sections, with microsecond accuracy. 337 338 The default measurement method is a maximum search, which is 339 disabled by default and can be runtime (re-)started 340 via: 341 342 echo 0 > /sys/kernel/debug/tracing/tracing_max_latency 343 344 (Note that kernel size and overhead increase with this option 345 enabled. This option and the preempt-off timing option can be 346 used together or separately.) 347 348config PREEMPT_TRACER 349 bool "Preemption-off Latency Tracer" 350 default n 351 depends on PREEMPTION 352 select GENERIC_TRACER 353 select TRACER_MAX_TRACE 354 select RING_BUFFER_ALLOW_SWAP 355 select TRACER_SNAPSHOT 356 select TRACER_SNAPSHOT_PER_CPU_SWAP 357 select TRACE_PREEMPT_TOGGLE 358 help 359 This option measures the time spent in preemption-off critical 360 sections, with microsecond accuracy. 361 362 The default measurement method is a maximum search, which is 363 disabled by default and can be runtime (re-)started 364 via: 365 366 echo 0 > /sys/kernel/debug/tracing/tracing_max_latency 367 368 (Note that kernel size and overhead increase with this option 369 enabled. This option and the irqs-off timing option can be 370 used together or separately.) 371 372config SCHED_TRACER 373 bool "Scheduling Latency Tracer" 374 select GENERIC_TRACER 375 select CONTEXT_SWITCH_TRACER 376 select TRACER_MAX_TRACE 377 select TRACER_SNAPSHOT 378 help 379 This tracer tracks the latency of the highest priority task 380 to be scheduled in, starting from the point it has woken up. 381 382config HWLAT_TRACER 383 bool "Tracer to detect hardware latencies (like SMIs)" 384 select GENERIC_TRACER 385 help 386 This tracer, when enabled will create one or more kernel threads, 387 depending on what the cpumask file is set to, which each thread 388 spinning in a loop looking for interruptions caused by 389 something other than the kernel. For example, if a 390 System Management Interrupt (SMI) takes a noticeable amount of 391 time, this tracer will detect it. This is useful for testing 392 if a system is reliable for Real Time tasks. 393 394 Some files are created in the tracing directory when this 395 is enabled: 396 397 hwlat_detector/width - time in usecs for how long to spin for 398 hwlat_detector/window - time in usecs between the start of each 399 iteration 400 401 A kernel thread is created that will spin with interrupts disabled 402 for "width" microseconds in every "window" cycle. It will not spin 403 for "window - width" microseconds, where the system can 404 continue to operate. 405 406 The output will appear in the trace and trace_pipe files. 407 408 When the tracer is not running, it has no affect on the system, 409 but when it is running, it can cause the system to be 410 periodically non responsive. Do not run this tracer on a 411 production system. 412 413 To enable this tracer, echo in "hwlat" into the current_tracer 414 file. Every time a latency is greater than tracing_thresh, it will 415 be recorded into the ring buffer. 416 417config OSNOISE_TRACER 418 bool "OS Noise tracer" 419 select GENERIC_TRACER 420 help 421 In the context of high-performance computing (HPC), the Operating 422 System Noise (osnoise) refers to the interference experienced by an 423 application due to activities inside the operating system. In the 424 context of Linux, NMIs, IRQs, SoftIRQs, and any other system thread 425 can cause noise to the system. Moreover, hardware-related jobs can 426 also cause noise, for example, via SMIs. 427 428 The osnoise tracer leverages the hwlat_detector by running a similar 429 loop with preemption, SoftIRQs and IRQs enabled, thus allowing all 430 the sources of osnoise during its execution. The osnoise tracer takes 431 note of the entry and exit point of any source of interferences, 432 increasing a per-cpu interference counter. It saves an interference 433 counter for each source of interference. The interference counter for 434 NMI, IRQs, SoftIRQs, and threads is increased anytime the tool 435 observes these interferences' entry events. When a noise happens 436 without any interference from the operating system level, the 437 hardware noise counter increases, pointing to a hardware-related 438 noise. In this way, osnoise can account for any source of 439 interference. At the end of the period, the osnoise tracer prints 440 the sum of all noise, the max single noise, the percentage of CPU 441 available for the thread, and the counters for the noise sources. 442 443 In addition to the tracer, a set of tracepoints were added to 444 facilitate the identification of the osnoise source. 445 446 The output will appear in the trace and trace_pipe files. 447 448 To enable this tracer, echo in "osnoise" into the current_tracer 449 file. 450 451config TIMERLAT_TRACER 452 bool "Timerlat tracer" 453 select OSNOISE_TRACER 454 select GENERIC_TRACER 455 help 456 The timerlat tracer aims to help the preemptive kernel developers 457 to find sources of wakeup latencies of real-time threads. 458 459 The tracer creates a per-cpu kernel thread with real-time priority. 460 The tracer thread sets a periodic timer to wakeup itself, and goes 461 to sleep waiting for the timer to fire. At the wakeup, the thread 462 then computes a wakeup latency value as the difference between 463 the current time and the absolute time that the timer was set 464 to expire. 465 466 The tracer prints two lines at every activation. The first is the 467 timer latency observed at the hardirq context before the 468 activation of the thread. The second is the timer latency observed 469 by the thread, which is the same level that cyclictest reports. The 470 ACTIVATION ID field serves to relate the irq execution to its 471 respective thread execution. 472 473 The tracer is build on top of osnoise tracer, and the osnoise: 474 events can be used to trace the source of interference from NMI, 475 IRQs and other threads. It also enables the capture of the 476 stacktrace at the IRQ context, which helps to identify the code 477 path that can cause thread delay. 478 479config MMIOTRACE 480 bool "Memory mapped IO tracing" 481 depends on HAVE_MMIOTRACE_SUPPORT && PCI 482 select GENERIC_TRACER 483 help 484 Mmiotrace traces Memory Mapped I/O access and is meant for 485 debugging and reverse engineering. It is called from the ioremap 486 implementation and works via page faults. Tracing is disabled by 487 default and can be enabled at run-time. 488 489 See Documentation/trace/mmiotrace.rst. 490 If you are not helping to develop drivers, say N. 491 492config ENABLE_DEFAULT_TRACERS 493 bool "Trace process context switches and events" 494 depends on !GENERIC_TRACER 495 select TRACING 496 help 497 This tracer hooks to various trace points in the kernel, 498 allowing the user to pick and choose which trace point they 499 want to trace. It also includes the sched_switch tracer plugin. 500 501config FTRACE_SYSCALLS 502 bool "Trace syscalls" 503 depends on HAVE_SYSCALL_TRACEPOINTS 504 select GENERIC_TRACER 505 select KALLSYMS 506 help 507 Basic tracer to catch the syscall entry and exit events. 508 509config TRACER_SNAPSHOT 510 bool "Create a snapshot trace buffer" 511 select TRACER_MAX_TRACE 512 help 513 Allow tracing users to take snapshot of the current buffer using the 514 ftrace interface, e.g.: 515 516 echo 1 > /sys/kernel/debug/tracing/snapshot 517 cat snapshot 518 519config TRACER_SNAPSHOT_PER_CPU_SWAP 520 bool "Allow snapshot to swap per CPU" 521 depends on TRACER_SNAPSHOT 522 select RING_BUFFER_ALLOW_SWAP 523 help 524 Allow doing a snapshot of a single CPU buffer instead of a 525 full swap (all buffers). If this is set, then the following is 526 allowed: 527 528 echo 1 > /sys/kernel/debug/tracing/per_cpu/cpu2/snapshot 529 530 After which, only the tracing buffer for CPU 2 was swapped with 531 the main tracing buffer, and the other CPU buffers remain the same. 532 533 When this is enabled, this adds a little more overhead to the 534 trace recording, as it needs to add some checks to synchronize 535 recording with swaps. But this does not affect the performance 536 of the overall system. This is enabled by default when the preempt 537 or irq latency tracers are enabled, as those need to swap as well 538 and already adds the overhead (plus a lot more). 539 540config TRACE_BRANCH_PROFILING 541 bool 542 select GENERIC_TRACER 543 544choice 545 prompt "Branch Profiling" 546 default BRANCH_PROFILE_NONE 547 help 548 The branch profiling is a software profiler. It will add hooks 549 into the C conditionals to test which path a branch takes. 550 551 The likely/unlikely profiler only looks at the conditions that 552 are annotated with a likely or unlikely macro. 553 554 The "all branch" profiler will profile every if-statement in the 555 kernel. This profiler will also enable the likely/unlikely 556 profiler. 557 558 Either of the above profilers adds a bit of overhead to the system. 559 If unsure, choose "No branch profiling". 560 561config BRANCH_PROFILE_NONE 562 bool "No branch profiling" 563 help 564 No branch profiling. Branch profiling adds a bit of overhead. 565 Only enable it if you want to analyse the branching behavior. 566 Otherwise keep it disabled. 567 568config PROFILE_ANNOTATED_BRANCHES 569 bool "Trace likely/unlikely profiler" 570 select TRACE_BRANCH_PROFILING 571 help 572 This tracer profiles all likely and unlikely macros 573 in the kernel. It will display the results in: 574 575 /sys/kernel/debug/tracing/trace_stat/branch_annotated 576 577 Note: this will add a significant overhead; only turn this 578 on if you need to profile the system's use of these macros. 579 580config PROFILE_ALL_BRANCHES 581 bool "Profile all if conditionals" if !FORTIFY_SOURCE 582 select TRACE_BRANCH_PROFILING 583 help 584 This tracer profiles all branch conditions. Every if () 585 taken in the kernel is recorded whether it hit or miss. 586 The results will be displayed in: 587 588 /sys/kernel/debug/tracing/trace_stat/branch_all 589 590 This option also enables the likely/unlikely profiler. 591 592 This configuration, when enabled, will impose a great overhead 593 on the system. This should only be enabled when the system 594 is to be analyzed in much detail. 595endchoice 596 597config TRACING_BRANCHES 598 bool 599 help 600 Selected by tracers that will trace the likely and unlikely 601 conditions. This prevents the tracers themselves from being 602 profiled. Profiling the tracing infrastructure can only happen 603 when the likelys and unlikelys are not being traced. 604 605config BRANCH_TRACER 606 bool "Trace likely/unlikely instances" 607 depends on TRACE_BRANCH_PROFILING 608 select TRACING_BRANCHES 609 help 610 This traces the events of likely and unlikely condition 611 calls in the kernel. The difference between this and the 612 "Trace likely/unlikely profiler" is that this is not a 613 histogram of the callers, but actually places the calling 614 events into a running trace buffer to see when and where the 615 events happened, as well as their results. 616 617 Say N if unsure. 618 619config BLK_DEV_IO_TRACE 620 bool "Support for tracing block IO actions" 621 depends on SYSFS 622 depends on BLOCK 623 select RELAY 624 select DEBUG_FS 625 select TRACEPOINTS 626 select GENERIC_TRACER 627 select STACKTRACE 628 help 629 Say Y here if you want to be able to trace the block layer actions 630 on a given queue. Tracing allows you to see any traffic happening 631 on a block device queue. For more information (and the userspace 632 support tools needed), fetch the blktrace tools from: 633 634 git://git.kernel.dk/blktrace.git 635 636 Tracing also is possible using the ftrace interface, e.g.: 637 638 echo 1 > /sys/block/sda/sda1/trace/enable 639 echo blk > /sys/kernel/debug/tracing/current_tracer 640 cat /sys/kernel/debug/tracing/trace_pipe 641 642 If unsure, say N. 643 644config KPROBE_EVENTS 645 depends on KPROBES 646 depends on HAVE_REGS_AND_STACK_ACCESS_API 647 bool "Enable kprobes-based dynamic events" 648 select TRACING 649 select PROBE_EVENTS 650 select DYNAMIC_EVENTS 651 default y 652 help 653 This allows the user to add tracing events (similar to tracepoints) 654 on the fly via the ftrace interface. See 655 Documentation/trace/kprobetrace.rst for more details. 656 657 Those events can be inserted wherever kprobes can probe, and record 658 various register and memory values. 659 660 This option is also required by perf-probe subcommand of perf tools. 661 If you want to use perf tools, this option is strongly recommended. 662 663config KPROBE_EVENTS_ON_NOTRACE 664 bool "Do NOT protect notrace function from kprobe events" 665 depends on KPROBE_EVENTS 666 depends on DYNAMIC_FTRACE 667 default n 668 help 669 This is only for the developers who want to debug ftrace itself 670 using kprobe events. 671 672 If kprobes can use ftrace instead of breakpoint, ftrace related 673 functions are protected from kprobe-events to prevent an infinite 674 recursion or any unexpected execution path which leads to a kernel 675 crash. 676 677 This option disables such protection and allows you to put kprobe 678 events on ftrace functions for debugging ftrace by itself. 679 Note that this might let you shoot yourself in the foot. 680 681 If unsure, say N. 682 683config UPROBE_EVENTS 684 bool "Enable uprobes-based dynamic events" 685 depends on ARCH_SUPPORTS_UPROBES 686 depends on MMU 687 depends on PERF_EVENTS 688 select UPROBES 689 select PROBE_EVENTS 690 select DYNAMIC_EVENTS 691 select TRACING 692 default y 693 help 694 This allows the user to add tracing events on top of userspace 695 dynamic events (similar to tracepoints) on the fly via the trace 696 events interface. Those events can be inserted wherever uprobes 697 can probe, and record various registers. 698 This option is required if you plan to use perf-probe subcommand 699 of perf tools on user space applications. 700 701config BPF_EVENTS 702 depends on BPF_SYSCALL 703 depends on (KPROBE_EVENTS || UPROBE_EVENTS) && PERF_EVENTS 704 bool 705 default y 706 help 707 This allows the user to attach BPF programs to kprobe, uprobe, and 708 tracepoint events. 709 710config DYNAMIC_EVENTS 711 def_bool n 712 713config PROBE_EVENTS 714 def_bool n 715 716config BPF_KPROBE_OVERRIDE 717 bool "Enable BPF programs to override a kprobed function" 718 depends on BPF_EVENTS 719 depends on FUNCTION_ERROR_INJECTION 720 default n 721 help 722 Allows BPF to override the execution of a probed function and 723 set a different return value. This is used for error injection. 724 725config FTRACE_MCOUNT_RECORD 726 def_bool y 727 depends on DYNAMIC_FTRACE 728 depends on HAVE_FTRACE_MCOUNT_RECORD 729 730config FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY 731 bool 732 depends on FTRACE_MCOUNT_RECORD 733 734config FTRACE_MCOUNT_USE_CC 735 def_bool y 736 depends on $(cc-option,-mrecord-mcount) 737 depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY 738 depends on FTRACE_MCOUNT_RECORD 739 740config FTRACE_MCOUNT_USE_OBJTOOL 741 def_bool y 742 depends on HAVE_OBJTOOL_MCOUNT 743 depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY 744 depends on !FTRACE_MCOUNT_USE_CC 745 depends on FTRACE_MCOUNT_RECORD 746 select OBJTOOL 747 748config FTRACE_MCOUNT_USE_RECORDMCOUNT 749 def_bool y 750 depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY 751 depends on !FTRACE_MCOUNT_USE_CC 752 depends on !FTRACE_MCOUNT_USE_OBJTOOL 753 depends on FTRACE_MCOUNT_RECORD 754 755config TRACING_MAP 756 bool 757 depends on ARCH_HAVE_NMI_SAFE_CMPXCHG 758 help 759 tracing_map is a special-purpose lock-free map for tracing, 760 separated out as a stand-alone facility in order to allow it 761 to be shared between multiple tracers. It isn't meant to be 762 generally used outside of that context, and is normally 763 selected by tracers that use it. 764 765config SYNTH_EVENTS 766 bool "Synthetic trace events" 767 select TRACING 768 select DYNAMIC_EVENTS 769 default n 770 help 771 Synthetic events are user-defined trace events that can be 772 used to combine data from other trace events or in fact any 773 data source. Synthetic events can be generated indirectly 774 via the trace() action of histogram triggers or directly 775 by way of an in-kernel API. 776 777 See Documentation/trace/events.rst or 778 Documentation/trace/histogram.rst for details and examples. 779 780 If in doubt, say N. 781 782config USER_EVENTS 783 bool "User trace events" 784 select TRACING 785 select DYNAMIC_EVENTS 786 depends on BROKEN || COMPILE_TEST # API needs to be straighten out 787 help 788 User trace events are user-defined trace events that 789 can be used like an existing kernel trace event. User trace 790 events are generated by writing to a tracefs file. User 791 processes can determine if their tracing events should be 792 generated by memory mapping a tracefs file and checking for 793 an associated byte being non-zero. 794 795 If in doubt, say N. 796 797config HIST_TRIGGERS 798 bool "Histogram triggers" 799 depends on ARCH_HAVE_NMI_SAFE_CMPXCHG 800 select TRACING_MAP 801 select TRACING 802 select DYNAMIC_EVENTS 803 select SYNTH_EVENTS 804 default n 805 help 806 Hist triggers allow one or more arbitrary trace event fields 807 to be aggregated into hash tables and dumped to stdout by 808 reading a debugfs/tracefs file. They're useful for 809 gathering quick and dirty (though precise) summaries of 810 event activity as an initial guide for further investigation 811 using more advanced tools. 812 813 Inter-event tracing of quantities such as latencies is also 814 supported using hist triggers under this option. 815 816 See Documentation/trace/histogram.rst. 817 If in doubt, say N. 818 819config TRACE_EVENT_INJECT 820 bool "Trace event injection" 821 depends on TRACING 822 help 823 Allow user-space to inject a specific trace event into the ring 824 buffer. This is mainly used for testing purpose. 825 826 If unsure, say N. 827 828config TRACEPOINT_BENCHMARK 829 bool "Add tracepoint that benchmarks tracepoints" 830 help 831 This option creates the tracepoint "benchmark:benchmark_event". 832 When the tracepoint is enabled, it kicks off a kernel thread that 833 goes into an infinite loop (calling cond_resched() to let other tasks 834 run), and calls the tracepoint. Each iteration will record the time 835 it took to write to the tracepoint and the next iteration that 836 data will be passed to the tracepoint itself. That is, the tracepoint 837 will report the time it took to do the previous tracepoint. 838 The string written to the tracepoint is a static string of 128 bytes 839 to keep the time the same. The initial string is simply a write of 840 "START". The second string records the cold cache time of the first 841 write which is not added to the rest of the calculations. 842 843 As it is a tight loop, it benchmarks as hot cache. That's fine because 844 we care most about hot paths that are probably in cache already. 845 846 An example of the output: 847 848 START 849 first=3672 [COLD CACHED] 850 last=632 first=3672 max=632 min=632 avg=316 std=446 std^2=199712 851 last=278 first=3672 max=632 min=278 avg=303 std=316 std^2=100337 852 last=277 first=3672 max=632 min=277 avg=296 std=258 std^2=67064 853 last=273 first=3672 max=632 min=273 avg=292 std=224 std^2=50411 854 last=273 first=3672 max=632 min=273 avg=288 std=200 std^2=40389 855 last=281 first=3672 max=632 min=273 avg=287 std=183 std^2=33666 856 857 858config RING_BUFFER_BENCHMARK 859 tristate "Ring buffer benchmark stress tester" 860 depends on RING_BUFFER 861 help 862 This option creates a test to stress the ring buffer and benchmark it. 863 It creates its own ring buffer such that it will not interfere with 864 any other users of the ring buffer (such as ftrace). It then creates 865 a producer and consumer that will run for 10 seconds and sleep for 866 10 seconds. Each interval it will print out the number of events 867 it recorded and give a rough estimate of how long each iteration took. 868 869 It does not disable interrupts or raise its priority, so it may be 870 affected by processes that are running. 871 872 If unsure, say N. 873 874config TRACE_EVAL_MAP_FILE 875 bool "Show eval mappings for trace events" 876 depends on TRACING 877 help 878 The "print fmt" of the trace events will show the enum/sizeof names 879 instead of their values. This can cause problems for user space tools 880 that use this string to parse the raw data as user space does not know 881 how to convert the string to its value. 882 883 To fix this, there's a special macro in the kernel that can be used 884 to convert an enum/sizeof into its value. If this macro is used, then 885 the print fmt strings will be converted to their values. 886 887 If something does not get converted properly, this option can be 888 used to show what enums/sizeof the kernel tried to convert. 889 890 This option is for debugging the conversions. A file is created 891 in the tracing directory called "eval_map" that will show the 892 names matched with their values and what trace event system they 893 belong too. 894 895 Normally, the mapping of the strings to values will be freed after 896 boot up or module load. With this option, they will not be freed, as 897 they are needed for the "eval_map" file. Enabling this option will 898 increase the memory footprint of the running kernel. 899 900 If unsure, say N. 901 902config FTRACE_RECORD_RECURSION 903 bool "Record functions that recurse in function tracing" 904 depends on FUNCTION_TRACER 905 help 906 All callbacks that attach to the function tracing have some sort 907 of protection against recursion. Even though the protection exists, 908 it adds overhead. This option will create a file in the tracefs 909 file system called "recursed_functions" that will list the functions 910 that triggered a recursion. 911 912 This will add more overhead to cases that have recursion. 913 914 If unsure, say N 915 916config FTRACE_RECORD_RECURSION_SIZE 917 int "Max number of recursed functions to record" 918 default 128 919 depends on FTRACE_RECORD_RECURSION 920 help 921 This defines the limit of number of functions that can be 922 listed in the "recursed_functions" file, that lists all 923 the functions that caused a recursion to happen. 924 This file can be reset, but the limit can not change in 925 size at runtime. 926 927config RING_BUFFER_RECORD_RECURSION 928 bool "Record functions that recurse in the ring buffer" 929 depends on FTRACE_RECORD_RECURSION 930 # default y, because it is coupled with FTRACE_RECORD_RECURSION 931 default y 932 help 933 The ring buffer has its own internal recursion. Although when 934 recursion happens it wont cause harm because of the protection, 935 but it does cause an unwanted overhead. Enabling this option will 936 place where recursion was detected into the ftrace "recursed_functions" 937 file. 938 939 This will add more overhead to cases that have recursion. 940 941config GCOV_PROFILE_FTRACE 942 bool "Enable GCOV profiling on ftrace subsystem" 943 depends on GCOV_KERNEL 944 help 945 Enable GCOV profiling on ftrace subsystem for checking 946 which functions/lines are tested. 947 948 If unsure, say N. 949 950 Note that on a kernel compiled with this config, ftrace will 951 run significantly slower. 952 953config FTRACE_SELFTEST 954 bool 955 956config FTRACE_STARTUP_TEST 957 bool "Perform a startup test on ftrace" 958 depends on GENERIC_TRACER 959 select FTRACE_SELFTEST 960 help 961 This option performs a series of startup tests on ftrace. On bootup 962 a series of tests are made to verify that the tracer is 963 functioning properly. It will do tests on all the configured 964 tracers of ftrace. 965 966config EVENT_TRACE_STARTUP_TEST 967 bool "Run selftest on trace events" 968 depends on FTRACE_STARTUP_TEST 969 default y 970 help 971 This option performs a test on all trace events in the system. 972 It basically just enables each event and runs some code that 973 will trigger events (not necessarily the event it enables) 974 This may take some time run as there are a lot of events. 975 976config EVENT_TRACE_TEST_SYSCALLS 977 bool "Run selftest on syscall events" 978 depends on EVENT_TRACE_STARTUP_TEST 979 help 980 This option will also enable testing every syscall event. 981 It only enables the event and disables it and runs various loads 982 with the event enabled. This adds a bit more time for kernel boot 983 up since it runs this on every system call defined. 984 985 TBD - enable a way to actually call the syscalls as we test their 986 events 987 988config FTRACE_SORT_STARTUP_TEST 989 bool "Verify compile time sorting of ftrace functions" 990 depends on DYNAMIC_FTRACE 991 depends on BUILDTIME_MCOUNT_SORT 992 help 993 Sorting of the mcount_loc sections that is used to find the 994 where the ftrace knows where to patch functions for tracing 995 and other callbacks is done at compile time. But if the sort 996 is not done correctly, it will cause non-deterministic failures. 997 When this is set, the sorted sections will be verified that they 998 are in deed sorted and will warn if they are not. 999 1000 If unsure, say N 1001 1002config RING_BUFFER_STARTUP_TEST 1003 bool "Ring buffer startup self test" 1004 depends on RING_BUFFER 1005 help 1006 Run a simple self test on the ring buffer on boot up. Late in the 1007 kernel boot sequence, the test will start that kicks off 1008 a thread per cpu. Each thread will write various size events 1009 into the ring buffer. Another thread is created to send IPIs 1010 to each of the threads, where the IPI handler will also write 1011 to the ring buffer, to test/stress the nesting ability. 1012 If any anomalies are discovered, a warning will be displayed 1013 and all ring buffers will be disabled. 1014 1015 The test runs for 10 seconds. This will slow your boot time 1016 by at least 10 more seconds. 1017 1018 At the end of the test, statics and more checks are done. 1019 It will output the stats of each per cpu buffer. What 1020 was written, the sizes, what was read, what was lost, and 1021 other similar details. 1022 1023 If unsure, say N 1024 1025config RING_BUFFER_VALIDATE_TIME_DELTAS 1026 bool "Verify ring buffer time stamp deltas" 1027 depends on RING_BUFFER 1028 help 1029 This will audit the time stamps on the ring buffer sub 1030 buffer to make sure that all the time deltas for the 1031 events on a sub buffer matches the current time stamp. 1032 This audit is performed for every event that is not 1033 interrupted, or interrupting another event. A check 1034 is also made when traversing sub buffers to make sure 1035 that all the deltas on the previous sub buffer do not 1036 add up to be greater than the current time stamp. 1037 1038 NOTE: This adds significant overhead to recording of events, 1039 and should only be used to test the logic of the ring buffer. 1040 Do not use it on production systems. 1041 1042 Only say Y if you understand what this does, and you 1043 still want it enabled. Otherwise say N 1044 1045config MMIOTRACE_TEST 1046 tristate "Test module for mmiotrace" 1047 depends on MMIOTRACE && m 1048 help 1049 This is a dumb module for testing mmiotrace. It is very dangerous 1050 as it will write garbage to IO memory starting at a given address. 1051 However, it should be safe to use on e.g. unused portion of VRAM. 1052 1053 Say N, unless you absolutely know what you are doing. 1054 1055config PREEMPTIRQ_DELAY_TEST 1056 tristate "Test module to create a preempt / IRQ disable delay thread to test latency tracers" 1057 depends on m 1058 help 1059 Select this option to build a test module that can help test latency 1060 tracers by executing a preempt or irq disable section with a user 1061 configurable delay. The module busy waits for the duration of the 1062 critical section. 1063 1064 For example, the following invocation generates a burst of three 1065 irq-disabled critical sections for 500us: 1066 modprobe preemptirq_delay_test test_mode=irq delay=500 burst_size=3 1067 1068 What's more, if you want to attach the test on the cpu which the latency 1069 tracer is running on, specify cpu_affinity=cpu_num at the end of the 1070 command. 1071 1072 If unsure, say N 1073 1074config SYNTH_EVENT_GEN_TEST 1075 tristate "Test module for in-kernel synthetic event generation" 1076 depends on SYNTH_EVENTS 1077 help 1078 This option creates a test module to check the base 1079 functionality of in-kernel synthetic event definition and 1080 generation. 1081 1082 To test, insert the module, and then check the trace buffer 1083 for the generated sample events. 1084 1085 If unsure, say N. 1086 1087config KPROBE_EVENT_GEN_TEST 1088 tristate "Test module for in-kernel kprobe event generation" 1089 depends on KPROBE_EVENTS 1090 help 1091 This option creates a test module to check the base 1092 functionality of in-kernel kprobe event definition. 1093 1094 To test, insert the module, and then check the trace buffer 1095 for the generated kprobe events. 1096 1097 If unsure, say N. 1098 1099config HIST_TRIGGERS_DEBUG 1100 bool "Hist trigger debug support" 1101 depends on HIST_TRIGGERS 1102 help 1103 Add "hist_debug" file for each event, which when read will 1104 dump out a bunch of internal details about the hist triggers 1105 defined on that event. 1106 1107 The hist_debug file serves a couple of purposes: 1108 1109 - Helps developers verify that nothing is broken. 1110 1111 - Provides educational information to support the details 1112 of the hist trigger internals as described by 1113 Documentation/trace/histogram-design.rst. 1114 1115 The hist_debug output only covers the data structures 1116 related to the histogram definitions themselves and doesn't 1117 display the internals of map buckets or variable values of 1118 running histograms. 1119 1120 If unsure, say N. 1121 1122source "kernel/trace/rv/Kconfig" 1123 1124endif # FTRACE 1125