1. 内核驱动故障排查概述
内核驱动运行在操作系统最底层，拥有最高特权级。一旦驱动出现故障，轻则导致内核日志报错、设备不可用，重则引发系统死机、数据损坏。本章从常见故障类型、排查方法论和工具链三个维度建立整体认知，为后续深入学习动态打印与Oops栈回溯打下基础。
核心认知： 内核驱动故障排查的本质是“在受限环境中还原现场”。用户态程序崩溃可以重启进程，内核态崩溃往往意味着整个系统需要重启。因此，排查手段必须高效、低侵入、可复现。
1.1 常见内核驱动故障类型
根据故障表现和根因，内核驱动故障可归纳为以下四大类：
| 故障类型 | 典型表现 | 根因示例 | 排查难度 |
|---|---|---|---|
| 空指针解引用 | Oops 日志中显示 NULL pointer dereference，RIP 指向 mov [rax] 类指令 |
kmalloc 失败未检查返回值；设备移除后未清空指针 | 低 |
| 内存泄漏 | 系统运行一段时间后 free 命令显示可用内存持续下降；slabtop 显示特定缓存增长 |
每次 IO 操作分配内存但未释放；引用计数未递减 | 中 |
| 死锁 | 进程 D 状态（uninterruptible sleep）；cat /proc/lockdep 显示锁依赖环 |
spin_lock 嵌套顺序不一致；mutex 在中断上下文中使用 | 高 |
| 越界访问 / 缓冲区溢出 | 随机崩溃、数据结构被破坏、KASAN 报告 out-of-bounds |
copy_from_user 长度校验错误；数组索引未做边界检查 | 中 |
经验法则： 空指针和越界访问通常能通过 Oops 日志直接定位代码行；内存泄漏和死锁则需要结合动态追踪工具进行长时间监控。
1.2 排查方法论
内核驱动故障排查遵循“由外到内、由现象到根因”的递进式方法。以下流程图展示了标准排查路径：
排查过程强调两个关键原则：
- 可复现优先： 在修改代码前，先确保能稳定复现故障。不可复现的故障往往需要增加埋点后等待再次出现。
- 最小化修改： 每次只修改一个疑点，验证后再进行下一步。避免一次修改多处导致无法判断哪处修改生效。
1.3 工具链概览
Linux 内核社区提供了丰富的排查工具，按使用场景可分为以下四类：
| 工具类别 | 代表工具 | 适用场景 | 侵入性 |
|---|---|---|---|
| 日志与打印 | printk、dyndbg、trace_printk |
运行时观察函数调用、变量值、分支走向 | 低 |
| 动态追踪 | ftrace、perf、eBPF |
函数级延迟分析、调用频次统计、内存分配追踪 | 极低 |
| 内存检测 | KASAN、kmemleak、slub_debug |
越界访问、释放后使用、内存泄漏检测 | 中（需重新编译内核） |
| 崩溃分析 | kdump + crash、gdb + vmlinux |
系统崩溃后离线分析内存快照、调用栈、数据结构 | 高（需预留内存） |
注意： 本课程重点讲解 动态打印 (dyndbg) 和 Oops 栈回溯分析 两种技术。前者是低侵入的运行时观测手段，后者是崩溃后定位根因的核心方法。两者结合可以覆盖 80% 以上的内核驱动故障场景。
1.4 故障排查的“第一现场”原则
当内核驱动发生故障时，不要急于重启系统。以下操作可以帮助保留第一现场：
- 保存完整内核日志： 使用
dmesg -T > crash.log或通过串口捕获完整输出。 - 检查 /proc 和 /sys 文件系统： 记录
/proc/modules、/proc/meminfo、/proc/locks等关键状态。 - 触发 kdump（如果已配置）： 让系统自动保存 vmcore 供后续离线分析。
- 记录复现步骤： 包括触发条件、负载特征、内核版本、驱动版本。
以下 SVG 图展示了故障现场数据采集的完整流程：
最佳实践： 在开发阶段就开启
CONFIG_DYNAMIC_DEBUG 和 CONFIG_KALLSYMS_ALL，并保留未 strip 的 vmlinux 文件。这样在故障发生时，可以直接从 Oops 日志中的 RIP 地址反推出源代码行号，无需重新编译。
1.5 本章小结
内核驱动故障排查是一个系统性的工程，需要理解故障类型、掌握排查方法、熟练使用工具链。本章建立了以下核心认知：
- 四大常见故障类型：空指针、内存泄漏、死锁、越界访问，各有其典型表现和排查难度。
- 排查方法论遵循“现象收集 → 日志分析 → 分支定位 → 修复验证”的递进路径。
- 工具链覆盖日志打印、动态追踪、内存检测、崩溃分析四个维度，本课程聚焦动态打印和Oops栈回溯。
- 故障现场保留是高效排查的前提，不要急于重启。