ftrace原理

ftraceFunction Tracer是 Linux 内核内置的动态跟踪框架核心原理是编译时静态插桩 运行时动态代码修改Code Patching 高效环形缓冲区Ring Buffer实现对内核函数、事件、延迟等的低开销跟踪。核心组件与架构ftrace 整体分为框架层Framework和跟踪器Tracer两层依赖 tracefs原 debugfs提供用户接口框架层Framework代码修改引擎动态替换函数入口指令NOP ↔ Call。环形缓冲区Ring BufferPer-CPU 设计无锁读写存储跟踪数据。回调管理ftrace_opsRCU 保护的回调链表支持多跟踪器共存。过滤系统基于函数名、PID、模块等过滤减少无关数据。用户接口通过/sys/kernel/tracing/tracefs暴露控制与数据文件。跟踪器Tracerfunction tracer跟踪函数入口。function_graph tracer跟踪函数调用与返回绘制调用图。irqsoff/wakeup/preemptoff跟踪中断、抢占、调度延迟。trace_events静态跟踪点覆盖内核各子系统。kprobe/kretprobe动态探针跟踪任意指令 / 函数返回。函数跟踪Function Trace核心原理1. 编译时静态插桩-pg /-mfentry内核开启CONFIG_FUNCTION_TRACERGCC 用-pg旧或-mfentry新x86_64编译。每个函数入口插入调用指令x86_64call __fentry__5 字节ARM64bl __mcount内核链接时将所有插桩地址存入.mcount_loc段供运行时定位。2. 启动时初始化与零开销化内核启动ftrace_init()遍历.mcount_loc。动态代码修改Code Patching将所有call __fentry__替换为 5 字节 NOP0x90。此时无跟踪开销性能与未插桩内核一致。3. 运行时启用 / 禁用跟踪启用跟踪用户写/sys/kernel/tracing/available_tracers、set_ftrace_filter等文件。框架找到目标函数的 NOP 地址。原子替换为call ftrace_caller跳转至跟踪回调。函数执行时先进入ftrace_caller。ftrace_caller 流程保存寄存器现场架构相关。检查过滤是否跟踪此函数 / PID/CPU。执行注册的回调如记录函数名、IP、PID 到 Ring Buffer。恢复寄存器返回原函数执行。禁用跟踪将call ftrace_caller改回 NOP。事件跟踪Trace Events原理静态跟踪点Tracepoint内核代码中用TRACE_EVENT()宏定义如sched_switch、block_rq_issue。编译时生成桩函数trace_*显式内联在代码关键路径。默认不执行仅跳转分支注册回调后才执行数据记录。工作流程代码执行到trace_*点。判断是否有回调注册无则跳过。有则读取参数如进程 PID、设备号写入 Ring Buffer。用户通过/sys/kernel/tracing/events/控制。数据存储Per-CPU 环形缓冲区Ring Buffer设计每个 CPU 独立缓冲区无锁读写避免多核竞争。固定大小循环覆盖防止内存耗尽。写入跟踪回调直接写入当前 CPU 的缓冲区。读取用户读trace或trace_pipe框架聚合所有 CPU 数据输出。关键特性与优势动态零开销不跟踪时为 NOP性能无损跟踪时按需激活。架构无关抽象底层指令修改支持 x86_64、ARM64、MIPS 等。可扩展支持自定义 Tracer、与 eBPF 结合fentry/fexit。安全可靠代码修改用 stop_machine 或 RCU 保证原子性避免并行执行冲突。全面覆盖函数、中断、调度、I/O、内存、系统调用等全场景跟踪。ftrace与tracepointftrace 内核跟踪框架管理 buffer、控制、输出、各种 tracertracepoint 内核静态插桩点代码里写死的 hook 点关系ftrace 可以使用 tracepointtracepoint 不依赖 ftraceperf、eBPF 也能用内核文档定位tracepoint 是 ftrace 的一种跟踪源ftrace 内部有一个专门的 tracerevent tracer它做的事遍历所有/sys/kernel/tracing/events/xxx打开某个 event 时注册回调到对应 tracepoint回调函数把参数写入ftrace ring buffer所以tracepoint 提供 “钩子”ftrace 负责 “收集、缓存、输出”function tracer函数跟踪基于-pg /fentry函数入口动态修改指令NOP ↔ call能跟踪几乎所有内核函数开销较高动态、全局、侵入性强tracepoint事件跟踪基于内核代码中显式定义的静态点不修改代码只注册 / 卸载回调点数量有限但稳定、不随内核版本乱变开销极低是 ABI 稳定的官方接口一句话区别ftrace function抓函数调用tracepoint抓内核关键事件ftrace与kprobeftrace跟踪框架buffer、控制、输出kprobe动态断点机制可插在任意指令不只函数入口关系kprobe 可以基于 ftrace 实现现代内核kprobe 也可以基于 int3/breakpoint 实现传统ftrace 是 kprobe 的一种高性能后端Kernel Probe内核动态探针可以动态挂在任意内核地址指令不需要编译插桩、不需要源码、不需要 tracepoint三类探针kprobe任意指令kretprobe函数返回uprobe用户态对应 kprobe传统 kprobe 原理int3 断点把目标指令第一个字节替换为int30xcc执行到这里触发debug exception#BP异常处理函数里执行你的回调单步执行原指令恢复现场缺点异常开销高、SMP 复杂、影响性能。现代 kprobe基于 ftracekprobe-on-ftraceLinux 4.x 主流架构默认使用满足条件时目标是函数入口该函数有__fentry__插桩-pgkprobe不再用 int3而是直接复用 ftrace 的 NOP ↔ call 动态修改机制流程把函数入口的 NOP →call ftrace_callerftrace 回调里调用你注册的 kprobe 处理函数无异常、无断点、开销远低于 int3这就是kprobe ftrace 的动态用户机制原理位置开销稳定性ftrace function-pg 动态代码修改函数入口中一般tracepoint静态宏、回调代码固定点极低稳定 ABIkprobeint3断点异常任意指令高不稳定kprobeftrace复用 ftrace 桩函数入口中低不稳定一句话本质区别tracepoint静态、官方、稳定、少、低开销ftrace function动态、函数入口、中等开销kprobe动态、任意地址、最灵活、但不稳定ftrace与bpftracebpftrace 是基于 eBPF 的高级跟踪语言底层 99% 都复用 ftrace 体系tracepoint、kprobe、kretprobe、uprobe、perf_event、ring buffer 全是 ftrace 那套基础设施。ftrace 内核底层跟踪骨架bpftrace eBPF 前端 依赖 ftrace 做挂载点bpftrace 支持的所有探针类型kprobe→ 内核 kprobe可走 ftracekretprobe→ 内核 kretprobetracepoint→ 内核 tracepointuprobe→ 用户态探针uretprobeusdtfunc / fentry / fexit→直接 ftrace 原生接口性能最高全部都基于内核已有的tracepointkprobekprobe-on-ftraceftrace 的 ftrace_ops、fentry、mcountperf_event把 eBPF 程序挂上去原理总结ftrace 是一套静态插桩 动态激活 无锁缓冲的综合跟踪体系编译埋点-pg在函数入口留钩子。启动优化钩子改为 NOP零开销运行。运行激活按需将 NOP 换成跟踪调用捕获数据。高效存储Per-CPU Ring Buffer 低延迟记录。用户接口tracefs 控制与读取。它是内核调试、性能分析、问题定位的基础工具也是 perf、bpftool 等工具的底层依赖。