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