内核调试从printk到eBPF：动态追踪与可观测性实战

干过内核驱动开发的朋友应该都有这种经历：辛辛苦苦写了几百行模块代码，insmod 下去，系统直接给你一个 Panic，屏幕上一堆十六进制寄存器，你盯着那个调用栈，第一反应就是想骂人。内核态调试和用户态完全是两回事，没有 gdb 断点，没有 core dump，甚至连 printf 都得重新学一遍——因为它在这里叫 printk。从最原始的 printk 到 ftrace、kprobe，再到现在的 eBPF，这套 Linux 内核调试技术栈我用过一轮之后，最大的感受是：工具虽然在迭代，但核心思路从来没变——你得先让内核告诉你，它内部到底发生了什么。

这篇文章我打算按我实际排查问题的经验路径来讲，不是按手册顺序罗列。你会看到 printk 这类基础手段的合理打开方式，也会看到动态追踪是怎么一步步把“观测成本”降下来的。适合刚接触内核模块开发的人，也适合那些被诡异内核问题折磨过、想找更系统调试方法的嵌入式或系统开发者。

1. 调试内核为什么这么难：用户态思维在内核态会翻车

1.1 用户态与内核态调试的差异

在用户态写项目，printf 打日志，gdb 打断点，出了问题大不了重启进程，core dump 分析完就完事。但你面对内核的时候，这套方法论基本失效：内核崩溃等于整机宕机，没有进程让你“重启一下”，panic 之后留下的一屏寄存器转储也不像 core dump 那样能恢复出完整上下文。我一开始调驱动的时候，习惯性地想找个断点单步跟，结果发现连“断下来”这个动作本身都很危险——在中断上下文里停下来，系统调度就瘫了。

更重要的是，内核态天然并发。同一段代码可能跑在多个 CPU 核心、中断上下文、软中断、workqueue、进程上下文里，用户态那种单线程单步执行的经验完全不够用。很多诡异的问题只在高负载下出现，等你把调试器挂上去，问题反而消失了。这背后的本质原因是：你无法在不改变内核执行方式的情况下观察它。所以内核调试技术的发展史，本质上就是一部“尽可能少干扰系统、却又能看清系统内部状态”的历史。printk 是最初的答案，它足够简单，但副作用是慢；动态追踪是后来的演进，它做到了“按需插桩”。

1.2 调试内核需要先建立“可观测性”思维

既然内核态不适合实时打断，那就要换一个思路：不是“停下来看”，而是“让它自己把状态留出来”。日志是状态，trace 记录是状态，tracing 目录里的每个开关也是状态。你要做的第一件事，不是学某个具体工具，而是建立一个判断：我想观测的这条路径，允许多大程度的侵入？

拿这个标准去选工具，事情就清楚很多。如果你只是想知道“这个驱动模块有没有加载成功”，printk 是最合适的；如果你想知道“这个函数被谁调用了一万次”，printk 就不行了，因为打一万次日志系统早就被拖垮。这时候该上 ftrace 或者 kprobe。理解了这条分界线，下面这些工具在你眼里就不是一个个孤立功能，而是一条连续的光谱：printk 在最左侧，侵入性最高、信息获取最直接；动态追踪在最右侧，侵入性低、信息可以按需编程。

2. printk：50岁仍能打的基础日志设施

2.1 别再用裸 printk 了：日志级别与优先级过滤

printk 的入口和 printf 类似，但第一个坑就是日志级别。很多内核新手写的模块代码都是 printk("xxx\n") 这样裸用，默认级别落在 KERN_WARNING，最终进 /var/log/kern.log。问题在于，如果这个模块在正常流程里输出大量信息，默认级别会把日志刷到控制台，还会触发 console 的同步输出，性能直接被打折。

正确做法是用 pr_err、pr_warn、pr_info 这类封装，它们各自对应不同级别，而且配合 loglevel 内核参数可以统一控制。比如系统启动参数里加 loglevel=3，就能让低于 KERN_ERR 的消息全部静音。裸 printk 的级别受 /proc/sys/kernel/printk 的当前值影响，这个值在运行过程中可能被守护进程或人为改动，很容易出现“我明明打了日志，怎么控制台看不到”的困惑。所以我的习惯是：能用 pr_xxx 就不用裸函数，这样日志级别的行为是可预期的。

2.2 pr_fmt 与动态调试，printk 的进阶姿势

一个被很多人忽略的技巧是 pr_fmt。在内核模块源码里，通常在头文件包含之后定义：

c复制#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

这样每个 pr_info 的输出都会自动带上模块名。我调驱动时都会加这一行，日志量一大，grep 模块名能省很多时间。这个宏的意义不只是美观，它给了日志一个固定的可过滤标签，配合 dmesg | grep 或者日志采集系统都方便得多。

更高级一点的是 dynamic debug。Linux 内核提供了 dynamic_debug 机制：

bash复制echo 'module xxx +p' > /sys/kernel/debug/dynamic_debug/control

这条命令可以把原本以 pr_debug 编译进内核的调试信息动态打开，不需要重新编译和加载模块。对发行版内核来说，这个能力尤其珍贵：很多内核路径里已经用 pr_debug 埋好了点，默认不输出，遇到问题时你只要打开对应模块的调试开关就行，比到处找补丁重编内核靠谱得多。

2.3 printk 的并发安全与输出节奏

还有一个经验：printk 在极端并发下也可能会掩盖问题本身。往频繁调用的路径里塞 printk，会让执行速度放慢几个数量级，竞态问题可能因为你放慢节奏而消失。另外多核并发打印时消息交错，内核日志里经常看到半条消息拼在一起，排查时反而增加噪声。

所以 printk 适合“低频、关键事件、阶段标记”，不适合“高频采样”。我一般只在模块加载/卸载、设备探测成功/失败、关键状态迁移这些地方留 printk，真正要观测频繁路径时，直接用后面说的 ftrace 和 eBPF。简单说，printk 是拿来记录“发生了什么”的，不是拿来统计“发生了多少次”的。

3. 只读窗口不够用：从 /proc、/sys 到 debugfs 和 tracefs

3.1 /proc 和 /sys：内核给用户态的“状态窗口”

很多人没把 /proc 和 /sys 当成调试工具，但它确实是最早的、全系统可用的观测接口。/proc/slabinfo 看 slab 分配器状态，/proc/interrupts 看中断分布，/sys/kernel/debug 下的各种 knobs 其实是内核开发者自己留的开关。我以前排查中断问题时，cat /proc/interrupts 看到某个 CPU 上中断数暴涨，比盲目抓包快得多。

这类接口的优点是零成本，系统自带，查看状态不影响内核行为。但它们的局限也很明显：大多只能展示当前状态或累计统计，不能轻易打开一条新的观测路径。当你想回答“这个函数每次调用的参数是什么”时，这些文件已经帮不上忙了。

3.2 debugfs：驱动开发者自己留的百宝箱

debugfs 是专门给内核调试开的虚拟文件系统，挂载点通常在 /sys/kernel/debug。很多成熟的驱动和子系统都会在这里暴露调试节点。比如中断子系统有 irq_domain_mapping，GPIO 子系统可以直接读寄存器和方向配置。这里的关键价值在于：调试信息的获取路径是可编程的，驱动作者可以自定义格式化输出，甚至写一些控制节点来触发内部状态迁移。

缺点是 debugfs 的接口没有 ABI 稳定性约束，每个内核版本都可能变，所以你在网上查到的某个路径不一定在当前内核里存在。如果你自己写驱动，建议也在 debugfs 里挂几个只读文件，把寄存器状态、环形缓冲区、统计计数暴露出来，这对之后排查问题帮助巨大，而且代码量很小。

3.3 tracefs 与 tracepoints：从“看静态输出”到“抓动态事件”

tracefs 通常挂载在 /sys/kernel/tracing，这是 ftrace 前台的配置文件系统核心位置。与 printk 需要预先埋点不同，tracefs 提供了一批内核自动埋好的 tracepoints，比如 sched_switch、irq_handler_entry、kmalloc 之类。你只需要向 tracefs 里的文件写入事件开关，然后读 trace 文件，就能拿到指定事件流。

这种“跑完再开，看完就关”的模式，对系统性能影响远小于 printk，而且能按 CPU、按进程过滤。可以说 tracefs 是通向动态追踪的第一道门。我遇到无法定位的内核问题时，第一件事往往是去 tracefs 里打开几个相关 tracepoint，先看事件序列，再决定要不要上 kprobe 做更细的观测。

4. ftrace：内核自带的动态追踪框架，比你想象的强得多

4.1 function tracer：把每个函数调用变成一条记录

ftrace 内置在主流发行版内核里，几乎不用额外装东西。挂载 tracefs 后，把 current_tracer 改成 function，再去 set_ftrace_filter 里指定一个函数名，比如 __x64_sys_read，然后 cat trace，就能看到这个函数被谁调用了、调用层次是怎么走的。

原理上，ftrace 用编译器插桩（-pg 选项）在每个函数入口预埋了一个 mcount/bl 桩，打开对应 tracer 时，这些桩会跳转到 ftrace 的处理逻辑，记录当前函数地址和时间戳。正因为入口桩是静态编译的，function trace 对函数内部的局部变量和中间路径没有感知。想看更细，得用 function_graph 或 kprobe。但 function tracer 用来回答“这个函数为什么会进来”是足够高效的。

bash复制# 挂载 tracefs
mount -t tracefs nodev /sys/kernel/tracing
cd /sys/kernel/tracing
# 使用 function tracer 并过滤到目标函数
echo function > current_tracer
echo __x64_sys_read > set_ftrace_filter
echo 1 > tracing_on
cat trace
echo 0 > tracing_on

4.2 kprobe 事件：不需要重新编译的动态观测点

ftrace 里最强的一段是 kprobe_events。通过在 /sys/kernel/tracing/kprobe_events 里写一行，就可以在指定函数入口抓取寄存器参数：

code复制p:my_probe do_sys_open dfd=%di filename=%si flags=%dx

这一操作的妙处在于：它是动态的，不需要重新编译内核，只要符号表里有这个函数，kprobe 就能在对应的指令地址上打补丁。更妙的是它还可以分别注册 kprobe 和 kretprobe，在入口和返回各拿一次数据，把函数的耗时也算出来。很多抓调用栈、统计函数时延的场景，用 kprobe 事件就够了，不需要上 eBPF。

kprobe 事件还支持过滤条件，比如只关心 PID 为 1234 的进程，可以在事件定义后面加 if pid == 1234。这个功能在排查特定任务的问题时非常实用。

4.3 实战：追踪一个驱动函数为何被频繁调用

我遇到过一次网卡中断太多导致的 CPU 100%，当时用 ftrace 的 function_graph tracer 限定在网卡驱动某个 napi_poll 函数上，打开后立即抓到完整的调用栈，发现驱动在 poll 里调用了一个加锁的读寄存器函数，每次都造成调度器开销。如果是 printk，你无法在不改变时序的情况下插进这个路径；ftrace 虽然也有开销，但脉冲式地开几百毫秒抓一次，是没问题的。

这个方法我现在还经常用来验证“系统到底在哪些函数上耗时间”。拿到调用链之后，再配合 perf 或者 kprobe 做量化分析，定位效率比盲猜高很多。我建议每个做内核开发的人至少把 ftrace 的 function_graph 练熟，它是我最常用的“内核黑盒探针”。

5. kprobe/uprobe：在几乎不重编译的情况下给内核“做手术”

5.1 内核态动态插桩的机制与限制

kprobe 的工作原理可以简单理解成：在指令级上替换为一个 breakpoint 或跳转，让控制流先到 kprobe 的处理函数，执行完观测逻辑后再回到正常路径。所以它可以针对任意函数地址，包括不导出的符号（前提是能通过 kallsyms 查到地址）。

但要记住它的限制。它不能插桩到所有指令上，某些边界情况（比如指令在跳转表里、函数被优化成尾调用等）会失败。另外，kprobe handler 里不适合做太重的事，因为它是运行在中断上下文或异常上下文里的，频繁分配内存、睡眠都是大忌。如果 handler 处理太慢，反而会拖垮整个系统。

5.2 用户态 uprobe：不打断业务的前提下跟踪应用函数

除了内核函数，动态追踪还能跟踪用户态函数。uprobe 的用法和 kprobe 很类似，写到 tracefs 的 uprobe_events 里，格式类似：

code复制p:my_prog /usr/bin/foo:0x1234

以前我们排查一个用户态守护进程频繁调用某个时间函数影响性能的问题，直接在对应二进制符号地址上注册 uprobe，记录调用次数和耗时，完全没有重启进程。对于没有源码、只有编译产物的场景，这种能力尤其珍贵。

uprobe 的实现是在用户态指令地址上打补丁，进程正常执行到该地址时会陷入内核，执行完观测逻辑再返回。它不需要改业务代码，也不要求符号表非得是 debug 格式，只要能从 ELF 文件里找到函数偏移就行。不过它也是侵入式的，如果被观测函数是热路径，开销会体现在 P95 延迟上，要谨慎使用。

5.3 kprobe vs uprobe 的选型逻辑

我的经验是：优先查内核是否已经有对应 tracepoint，如果没有再用 kprobe。用户态问题优先考虑 uprobe，因为它的观测对象是用户态代码，行为更可控。如果问题跨越了用户态和内核态，比如文件读写路径，那就需要 kprobe 和 uprobe 配合，再结合 tracepoint 里的文件系统事件，拼出完整时间线。

6. eBPF：从“观测”到“可编程观测”的进化

6.1 eBPF 在内核调试体系中的位置

eBPF 和前面几种手段不是替代关系，而是把动态追踪的能力往前推了一步：kprobe/ftrace 负责“按条件插桩”，eBPF 负责“插桩之后的数据处理”。它允许你写一段小字节码挂载到 tracepoint、kprobe、甚至网络路径上，把采集到的数据在内核态做聚合、筛选，只有最终结果通过 map 传给用户态。好处是数据传输量小，对系统的附加负载更低。

从调试视角看，eBPF 最大的价值是“可编程”。kprobe 事件虽然能抓参数，但数据量大时用户态处理不过来；eBPF 直接在内核里完成计数、求均值、直方图统计，给出的已经不是原始日志，而是“结论”。比如你要统计某个函数调用的时延分布，用 eBPF 可以输出直方图，而不是几万行裸日志让你自己算。

6.2 bpftrace：几行脚本看内核事件

bpftrace 是上手最快的 eBPF 前端，语法有点像 awk。比如要统计内核里 do_sys_open 的调用次数和进程名，可以写：

code复制kprobe:do_sys_open {
    @[comm] = count();
}

跑几秒钟 Ctrl+C，它就会打印出每个进程调用 open 的次数。你不需要写 C，不需要编译内核模块，出结果的速度比写 printk 重编快几个数量级。我已经把 bpftrace 当成了排查性能问题的第一梯队工具，它尤其适合快速验证一个猜测：这个函数是不是被频繁调用？哪个进程在调用它？耗时分布如何？

bpftrace 还能看内核 tracepoint、用户态 USDT、甚至跟踪内核 slab 分配。遇到性能问题时，我常用它跑一段 10 秒的现场采样，把扇区读写、内存分配、锁竞争这些指标一次性拿到，比逐项排查高效得多。

6.3 libbpf 与 CO-RE：更精细的观测点写入

如果 bpftrace 满足不了你，比如需要读取特定内核结构体的字段、或者在事件里做更复杂的逻辑，那就得上 libbpf。CO-RE（Compile Once - Run Everywhere）解决的是内核版本差异问题，你的 BPF 程序在编译时记录下需要访问的结构体偏移，加载时由内核的 BTF 信息重新定位。

写一段跟踪函数入口的小程序，挂到 kprobe 上，比写内核模块安全很多，因为 BPF 验证器会在运行前做安全检查，非法内存访问直接被拒。下面是一个最小示例：

c复制#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>

SEC("kprobe/do_sys_open")
int BPF_KPROBE(do_sys_open_entry, int dfd, const char *filename, int flags)
{
    bpf_printk("open called, dfd=%d, flags=%d\n", dfd, flags);
    return 0;
}

char LICENSE[] SEC("license") = "GPL";

编译好后用 bpftool 加载，查看 /sys/kernel/debug/tracing/trace_pipe 就能看到输出。这比直接改内核代码或模块加载流程要干净得多。缺点是编译链路复杂一些，需要 clang 和内核头文件，但对经常做系统问题排查的人来说，这套工具链值得花时间搭起来。

7. 实战复盘：一次“软死锁”告警的排查过程

7.1 现象：soft lockup 告警和“卡住”的驱动

有一回我的测试机上出现 soft lockup 告警，提示某个 CPU 核心长时间没有调度，但系统还能用，只是响应很慢。最初怀疑是死循环，但看 dmesg 并没有明显的 panic，只是 watchdog 把栈信息打印出来了。调用栈指向一个自研驱动的轮询函数，它在一个加了自旋锁的循环里等待硬件寄存器变化。

这个场景典型又危险：进程看起来卡死了，实际上是在某个临界区里转圈。如果当时直接上 gdb 或者 kgdb 打断点，极有可能把系统彻底搞死。稳妥的做法是从观测入手，先把“卡在哪里、等了多久”搞清楚。

7.2 用 ftrace 锁定路径，用 kprobe 测量耗时

我先用 ftrace 的 function_graph 追踪这个驱动函数的调用链，确认它是被一个高优先级线程持续调用；然后挂一个 kretprobe 到驱动里那个读寄存器函数上，统计每次调用的耗时。跑一分钟发现，大部分调用很快返回，但有极少数调用会卡到几十毫秒——这个数量级在高速路径里是不正常的。

于是我把观测重点放到“什么条件导致它 wait 这么久”，通过 kprobe 抓寄存器状态，发现是硬件寄存器里一个状态位读不到预期的值。整个定位过程没有重新编译过驱动，也没有改一行日志代码。如果是传统 debugfs 加打印，至少要经历“改代码—编译—部署—复现”的循环，在高并发现场基本不可行。

7.3 根因验证与修复

根因是驱动对硬件的探测时序没有做超时保护，在极端情况下会一直等一个永远不会来的中断。修复方案是给循环加超时和错误恢复状态机。修完后重新挂上同样的 kprobe，耗时分布恢复正常，soft lockup 告警也消失。

这次排查里 printk 只用在了最后的验证阶段，前期的定位全靠动态追踪——因为如果一上来就在驱动路径里加打印，极可能把时序进一步恶化，问题更难复现。这件事给我最大的启发是：动态追踪不是为了炫技，而是它真的能在“不改变问题现场”的情况下看到问题，这是传统手段做不到的。

8. 调试手段选型的三个原则与常见误区

8.1 优先选择对执行流干扰最小的方案

我的决策顺序是：能用 tracepoint 不用 kprobe，能用 kprobe 不重编译，能重编译就不用硬件调试器。原因很简单：观测本身会改变系统的行为，观测手段的侵入性越低，结论越可信。printk 适合低频标记，ftrace 适合高频调用链，eBPF 适合复杂聚合。这不是技术洁癖，而是被实际问题教育出来的：很多内核 bug 只在特定时序下触发，观测手段稍微改变时序，bug 就消失了，你说这算复现了还是没复现？

选型时还有一个反向原则：如果问题已经稳定复现，用侵入性高一点的手段也无妨；如果问题是偶发的，一定要用侵入性最低的手段，否则你抓到的永远是一个被观测行为改变过的伪现场。

8.2 别忽视符号表和 kallsyms

动态追踪依赖符号解析，如果内核开启了 KASLR，外部工具可能解析不到符号，但 ftrace 对内核自身符号是没问题的。真正麻烦的是被去掉符号的供应商内核（很多嵌入式产品就是这样），kprobe 会变得很难下手，这时往往只能回归 tracefs 里的静态 tracepoint。

有条件的情况下，建议保留 CONFIG_DEBUG_INFO，甚至 CONFIG_DEBUG_INFO_BTF。BTF 信息对 eBPF 的 CO-RE 至关重要，没有它，你再好的 BPF 程序也得为了适配内核版本反复编译。调试信息的代价无非是内核镜像大了点，但它给后续排查留了一条后路。别等出问题时才发现自己的内核连 kallsyms 都是精简的。

8.3 常用观测方式的开销与适用场景对比

8.4 调试代码记得清理，观测点不是功能

最后一个经验是：调试代码和观测点用完一定要清理。我见过不少驱动带着一堆调试打印直接上生产，结果日志文件把根分区写满；也见过 debugfs 节点没有做权限控制，被用户态程序触发内部状态迁移。调试设施的定位是“开发期的辅助手段”，上线前应该审视一遍，能关的关，能删的删。

但我不会建议把所有观测点都删掉，有些高价值的 tracepoint 和 ftrace 事件是内核自带能力，留着不影响性能。真正该删的是你临时加的 printk、临时挂的 kprobe、以及那些没有超时保护的自制调试接口。把这个习惯养好，你会少很多线上事故。

最后再分享一个我自己踩过的坑：有一次我在一个频繁调用的 ISR 里留了一行 printk，本来只是想确认中断频率，结果日志输出直接让系统陷入半死状态。后来我养成了习惯，但凡要观测高频路径，第一选择永远是 ftrace 或者 kprobe，printk 只留给“这条路径被执行了”这种低频信号。工具用对了，内核调试其实没那么可怕。