Linux中ftrace的available_filter_functions收录函数的判定标准是什么？

这是个很常见的ftrace疑问，其实除了文档提到的内联函数，还有几个关键因素决定了一个函数是否会出现在/sys/kernel/debug/tracing/available_filter_functions列表里，我来拆解一下：

• 函数的编译可见性与存活状态
  如果一个函数被标记为static，且编译器判断它只在当前编译单元（也就是你说的blk-mq.c）内部被调用，甚至可能被完全内联或者优化删除，那它的符号不会被导出到内核全局符号表，ftrace自然无法探测到它。另外，有些函数会被内核配置宏（比如CONFIG_BLK_MQ_*这类）包裹，如果对应的配置项没开启，这个函数根本不会被编译进内核，当然也不会出现在列表里。

• 内核的追踪限制属性
  内核里部分函数会被标记__attribute__((no_trace))或者类似的特殊属性，这类函数是被明确禁止ftrace追踪的——通常是一些核心的底层函数（比如调度、锁相关），避免追踪操作本身引发死锁或者性能问题。如果blk_mq_add_queue_tag_set带有这类属性，它就不会出现在可用列表中。

• 编译器的优化行为
  即使函数不是static，编译器在O2/O3优化级别下，可能会把一些短函数直接内联到调用点，或者将函数的符号从符号表中隐藏（比如通过-fvisibility=hidden编译选项）。这种情况下，函数没有独立的入口点，ftrace无法插入探测代码，也就不会被收录。

针对你提到的例子，你可以做两个简单验证：

1. 查看内核源码中blk_mq_add_queue_tag_set的定义，确认是否带有static修饰、是否被配置宏包裹，或者是否有__no_trace属性；
2. 查看/proc/kallsyms文件，如果这个函数的符号不存在，说明它要么没被编译，要么被编译器优化掉了。

内容的提问来源于stack exchange，提问作者codexplorer