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