📚 课程目录第2章 Ftrace工作原理

2、Ftrace工作原理：静态探测点与动态探测点的实现机制

Ftrace 是 Linux 内核内置的追踪框架，其核心价值在于能够以极低的开销捕获内核函数的执行流。理解 Ftrace 的工作原理，关键在于区分其两大探测机制：静态探测点（Static Tracepoint）与动态探测点（Dynamic Tracepoint / kprobe-based）。这两种机制共同支撑了从函数级到事件级的全方位追踪能力。

2.1 静态探测点（Static Tracepoint）

静态探测点是在内核编译阶段由开发者预先插入的固定追踪钩子。这些钩子通常位于关键子系统（如调度、中断、内存管理）的路径上，通过 trace_() 宏实现。

  核心特征： 静态探测点默认被编译为 nop 指令（空操作），仅在用户启用对应事件时，Ftrace 才会将 nop 动态替换为 call 指令，跳转到追踪处理函数。这种设计实现了“零开销除非启用”的效果。

2.1.1 实现机制

编译时插入： 内核开发者使用 DECLARE_EVENT_CLASS 和 DEFINE_EVENT 宏定义事件类与实例。编译器在指定位置生成一个 nop 指令占位符。
运行时激活： 用户通过 echo 1 > /sys/kernel/tracing/events/sched/sched_switch/enable 激活事件。Ftrace 内核模块将对应地址的 nop 指令修改为 call trace_event_raw_event_sched_switch。
数据收集： 当内核执行到该路径时，CPU 执行 call 指令，进入预定义的追踪函数，将事件数据写入 per-CPU 环形缓冲区。

适用场景： 调度切换、系统调用入口/出口、IRQ 中断、内存回收等内核核心路径。静态探测点稳定性极高，适合生产环境长期监控。

2.2 动态探测点（Dynamic Tracepoint / kprobe）

动态探测点允许用户在不重新编译内核的情况下，对任意内核函数进行追踪。其底层依赖 kprobe（内核探测点）机制，通过指令级替换实现断点。

2.2.1 实现机制

指令替换： 当用户指定追踪函数 do_sys_open 时，Ftrace 将函数入口处的第一条指令（通常是 push rbp 或 nop）替换为 int3 断点指令（0xCC）。
断点触发： CPU 执行到 int3 时触发 #BP 异常，进入内核的 do_int3 处理函数。
回调执行： do_int3 识别出该地址属于 Ftrace 动态探测点，调用用户注册的回调函数（如 ftrace_ops 中的 func）。
单步执行： 回调执行完毕后，Ftrace 将原始指令放回，并设置 CPU 单步标志（TF），执行原始指令后恢复断点，继续正常流程。

注意事项： 动态探测点对函数入口（fentry）和函数出口（fexit）均有支持。但探测 inline 函数或被优化掉的函数时可能失败。生产环境使用前建议在测试环境验证。

2.3 静态 vs 动态：对比分析

对比维度	静态探测点	动态探测点
插入方式	编译时由开发者预埋	运行时通过指令替换动态注入
稳定性	极高，经过内核主线验证	较高，但存在指令替换风险（如抢占问题）
灵活性	只能追踪预定义事件	可追踪任意非内联函数
性能开销	未启用时为零开销	即使未启用，函数入口也需检查（`ftrace_caller`）
典型用途	调度、中断、系统调用等标准事件	自定义函数调用链分析、驱动调试

2.4 tracefs 文件系统的挂载与结构

Ftrace 的所有控制接口与数据输出均通过 tracefs 虚拟文件系统暴露。tracefs 通常挂载在 /sys/kernel/tracing 目录下，是用户与 Ftrace 交互的唯一入口。

2.4.1 挂载方式

# 手动挂载（如果未自动挂载）
mount -t tracefs tracefs /sys/kernel/tracing

# 确认挂载状态
mount | grep tracefs
# 输出示例：tracefs on /sys/kernel/tracing type tracefs (rw,relatime)

提示： 现代 Linux 发行版（内核 4.x+）通常在系统启动时通过 sysfs 自动挂载 tracefs。如果 /sys/kernel/tracing 目录为空，请执行上述手动挂载命令。

2.4.2 核心目录与文件结构

tracefs 的目录结构层次分明，主要分为控制接口、事件目录、追踪数据输出三大类。下表列出了最常用的文件与目录：

路径	类型	功能描述
`available_tracers`	文件	列出当前内核支持的追踪器类型（如 function、function_graph、nop）
`current_tracer`	文件	设置或查看当前激活的追踪器
`tracing_on`	文件	全局追踪开关（1 开启，0 关闭）
`trace`	文件	输出当前环形缓冲区中的追踪数据（人类可读格式）
`trace_pipe`	文件	流式输出追踪数据，支持 `cat` 持续读取
`set_ftrace_filter`	文件	设置要追踪的函数白名单（支持通配符）
`set_ftrace_notrace`	文件	设置要排除的函数黑名单
`events/`	目录	包含所有静态事件子目录（如 `events/sched/sched_switch`）
`kprobe_events`	文件	动态 kprobe 事件的定义接口
`instances/`	目录	支持创建独立的追踪实例，实现多租户隔离

2.4.3 目录结构示意图

下图展示了 tracefs 挂载点下的核心层级关系，帮助理解各组件之间的组织逻辑：

2.5 动态探测点与静态探测点的协作流程

在实际调试中，静态探测点和动态探测点经常协同工作。例如，先通过静态事件定位到问题子系统，再使用动态探测点深入分析特定函数。下图展示了两种探测点在 Ftrace 框架中的完整协作流程：

2.6 关键数据结构：ftrace_ops

无论是静态还是动态探测点，最终都通过 struct ftrace_ops 结构体注册到 Ftrace 核心。该结构体是连接探测点与回调函数的桥梁：

struct ftrace_ops {
    ftrace_func_t       func;           // 回调函数指针
    struct ftrace_ops   *next;          // 链表指针，支持多 ops 链式调用
    unsigned long       flags;          // 控制标志（如 FTRACE_OPS_FL_SAVE_REGS）
    int                 (*trampoline)(unsigned long ip, unsigned long parent_ip,
                                     struct ftrace_ops *ops, struct pt_regs *regs);
    // ... 其他内部字段
};

  关键点： ftrace_ops 的 func 字段定义了当探测点命中时执行的回调。用户可以通过 register_ftrace_function() 注册自定义 ops，实现内核模块级别的动态追踪。

2.7 本章小结

静态探测点 依赖编译时预埋的 nop 指令，通过运行时指令修补实现零开销激活，适合标准事件追踪。
动态探测点 基于 int3 断点机制，可对任意函数进行追踪，灵活性高但需注意指令替换风险。
tracefs 挂载于 /sys/kernel/tracing，提供了完整的控制接口（current_tracer、set_ftrace_filter）和数据输出接口（trace、trace_pipe）。
理解两种探测点的实现机制，是后续进行函数追踪参数配置和故障排查的理论基础。