linux kernel debug记录一份来自一线的排障全流程linux kernel debug这件事说难也难说简单也简单。难在崩溃现场往往一闪而过简单在只要掌握了日志和工具的用法大部分问题都能从内核自己留下的线索里找到答案。我这些年调试过的内核问题不算少从启动阶段的模块加载失败到驱动运行时的随机崩溃再到文件系统层的读写拦截失效踩过的坑多了慢慢也就沉淀出了一套自己的排障流程。这篇文章不是什么教材就是我基于实际项目经验总结出来的Linux内核调试笔记覆盖启动日志分析、动态调试、崩溃定位、模块加载失败这几类最常见的场景希望能给正在跟内核问题搏斗的朋友一些参考。内核调试和普通应用程序调试最大的区别在于你没有断点可用至少第一现场没有数据和现场全靠日志和系统留下的记录来还原。所以整个调试过程的核心思路就是先最快找到第一现场的痕迹再顺着痕迹一步一步把问题从代码层面还原出来。理解了这条主线所有工具和方法其实都是在为它服务。1. 内核调试的第一现场启动日志与模块加载1.1 内核启动流程中日志的定位逻辑内核调试的第一步永远是看日志而且是按时间线和层级看。Linux内核从开机到进入用户空间经历的大致流程是引导程序加载内核镜像然后内核解压自身进行架构相关的初始化再到内核核心子系统初始化最后挂载根文件系统并启动第一个用户进程。这个过程中每一阶段都有对应的日志输出只是输出目标不同。早期架构初始化阶段的打印可能只能通过串口看到到了内核主线初始化阶段dmesg里就已经能看到了。搞清楚日志层级对后续排查特别重要。很多人一上来就dmesg一顿看结果被海量信息淹没。我习惯的做法是先查优先级高的消息比如dmesg -l err或dmesg -l crit先把最严重的错误过滤出来再结合emerg级别去看系统已经处于什么状态。内核日志按紧急程度分成emerg、alert、crit、err、warning、notice、info、debug八个等级默认console_loglevel可能是7或者更低这会导致某些debug信息不会输出到控制台但通常还是会写进内核日志缓冲区。所以不管屏幕上报了什么错第一件事都应该是用dmesg把完整日志抓下来。我遇到过太多次屏幕上只显示一行panic信息但完整调用栈和寄存器状态都藏在dmesg里如果只盯着屏幕看方向就完全跑偏了。1.2 从dmesg读懂一次模块加载失败模块加载失败是内核调试里最常见的问题也是最适合拿来入门分析流程的场景。拿网上一搜一大把的报错来举例比如“unable to load the kernel module nvidia.ko”或者VirtualBox的“kernel driver not installed (rc-1908)”。这类问题表面上看是模块加载失败但深层原因五花八门必须靠日志一步步排除。我自己常用的排查顺序是这样的先用lsmod确认模块当前状态看是不是已经加载过或者残留了旧版本。然后modinfo nvidia查看模块信息重点看vermagic字段这个字段记录了模块编译时对应的内核版本和SMP/Preemption配置。vermagic不匹配是内核模块加载失败的经典原因报错往往是“Invalid module format”或者“version magic mismatch”。接着modprobe nvidia尝试重新加载再用dmesg -l err查看内核报错。如果看到类似“Unknown symbol”或者“disagrees about version of symbol”的信息说明模块依赖的内核符号版本不一致。这种问题多半是因为模块是拿旧内核头文件编的而实际运行的内核已经升级过了。还有一类是直接看不到dmesg错误但模块就是加载不成功。这种情况要检查一下内核配置里的模块签名机制尤其是UEFI安全启动开启的机器未签名的第三方模块会被直接拒绝加载。dmesg | grep -i lockdown或者dmesg | grep -i sig能看到相关痕迹。最后还有个大坑是DKMS。很多人编译完模块后重启发现又加载的是旧版本这就是因为新编译的模块没有通过DKMS注册进内核模块目录重启后系统又从/lib/modules/$(uname -r)/下加载了旧文件。正确的做法是用DKMS编译安装而不是手动make install覆盖到别的路径。2. 动态调试让内核自己报告行踪2.1 利用dynamic debug机制按需打开调试信息静态日志只能看到问题发生后的结果很多时候我们需要在问题发生前就知道代码走了哪条路径。Linux内核的dynamic debug机制就是干这个的它允许运行中的内核动态打开或关闭特定文件、特定函数、特定行的printk/pr_info等调试输出而不需要重新编译内核和驱动模块。当初我刚接触dynamic debug时简直像发现了新世界。以前调试一个驱动要么在代码里手动加printk然后重新编译来回折腾半小时要么靠猜。dynamic debug把这些都省了。用法很直接。确认内核开启了CONFIG_DYNAMIC_DEBUG后通过debugfs挂载点操作。挂载方式mount -t debugfs none /sys/kernel/debug查看当前所有可动态开关的调试点cat /sys/kernel/debug/dynamic_debug/control按模块名精细控制输出echo module mydriver p /sys/kernel/debug/dynamic_debug/control按文件名控制适合调试特定源文件echo file drivers/net/myeth.c p /sys/kernel/debug/dynamic_debug/control还支持按函数控制echo func my_init p /sys/kernel/debug/dynamic_debug/control这套机制让我在排查驱动加载路径和中断处理路径时效率提升了好几倍。注意一点如果模块是用#define DEBUG或者-DDEBUG编译的很多printk会被编译器认为是静态启用的dynamic debug的开关就对它无效这个要提前在Makefile里了解清楚。2.2 用tracepoint和ftrace观察文件读写路径动态调试适合观察代码内部的执行流但如果你想搞清楚某个文件操作是否被调用、调用的参数是什么、返回值是什么用内核的tracepoint会更快。Linux的ftrace框架内置了大量跟踪点尤其是文件系统、调度器、块设备这些子系统都有现成的tracepoint可以挂接。这里特别说一下热词里经常有人搜“linux 内核 动态加载 file_operations 拦截 read write”这种需求往往是想在文件读写层做拦截或者透明加密。真到这一步调试的核心就是确认拦截逻辑有没有被正确调用。用ftrace就能很方便地验证。开启文件系统相关tracepoint的方法cd /sys/kernel/debug/tracing echo 0 tracing_on echo function_graph current_tracer echo do_sys_openat2 set_graph_function echo 1 tracing_on cat trace这样能看到do_sys_openat2被调用时的完整调用链路包括谁调用的、调用了哪些子函数。如果想看更细粒度的文件读写事件可以看看tracefs里events目录下的相关内容比如ext4、vfs层的事件。由于不同内核版本的事件路径有差异这里不写绝对路径。实际操作时可以用ls /sys/kernel/debug/tracing/events/自己找一下很直观。2.3 用kprobe在不改代码时探查内核行为有些情况下内核或者驱动里压根没有调试输出dynamic debug也帮不上忙编译一个带完整调试符号的内核又太耗时。这时候就该kprobe出场了。kprobe是内核提供的一种动态插桩机制允许在内核函数的入口、出口甚至指定指令处动态插入探针收集寄存器、参数、返回值等信息完全不需要修改内核代码也不需要重新编译。我经常用kprobe event的方式来做快速验证。挂载tracefs后通过以下方式创建探针cd /sys/kernel/debug/tracing echo p:myprobe vfs_read file%di count%dx kprobe_events echo 1 events/kprobes/myprobe/enable然后用cat trace查看探针输出。这里的%di是x86_64架构下第一个参数所在寄存器%dx是第三个参数所在寄存器。不同架构寄存器不一样ARM64下第一个参数是%x0x86下用%di知道后按需调整即可。kprobe的真正价值在于可以在不惊动业务进程的前提下确认某个内核函数有没有被调用、调用频率多高、参数是否合理。比如之前遇到一个随机崩溃问题怀疑是某驱动在特定路径下没有正确加锁我用kprobe挂在锁函数和关键路径函数上通过观察两者的调用顺序很快就锁定了问题出在哪个竞态窗口。这个思路特别适合追查偶发性问题因为探针本身对系统性能影响很小可以一直开着等现场自己出现。3. 崩溃现场从Oops到panic的完整定位链路3.1 一份Oops日志里藏了哪些关键信息内核崩溃的核心产物是Oops信息或者panic信息panic通常意味着系统完全无法继续运行Oops则是当前进程被杀死系统还可以继续。很多人看到一堆十六进制地址就头疼其实Oops日志里最重要的信息就那么几块。拿真实场景来说一份典型Oops日志包含错误类型如“BUG: unable to handle kernel NULL pointer dereference at ...”这是最直接的定性信息告诉你发生了什么类型的错误。出错地址和触发地址包括出错指令的虚拟地址、访问的地址等。RIP/RETRACE信息x86架构下RIP寄存器指向当前指令后面那一串函数调用链就是栈回溯。Call Trace整个调用链列表这是定位代码路径的最关键线索。寄存器快照包含通用寄存器值很多东西都能从这里看出来。内核版本、RIP对应符号、代码段偏移等等。我第一次看到Oops时完全抓瞎后来总结出快速阅读顺序先看第一行确认错误类型然后看RIP那一行确认出事的函数名再看Call Trace整条链路最后结合寄存器和Code/AOD信息验证。这样下来大部分空指针、野指针、越界访问问题都能在几分钟内定位到具体函数。3.2 用addr2line把地址翻译成代码行有了Callback信息还不够我们最终需要的是代码行号。这就要用上编译时生成的vmlinux文件和addr2line工具。前提是内核编译时开了CONFIG_DEBUG_INFO否则符号表和行号信息都不完整。建议调试环境的内核都开启这个选项生产环境倒是可以关掉减小体积也避免泄露内部符号。实际用法很简单addr2line -f -e /usr/lib/debug/boot/vmlinux-$(uname -r) ffffffff81001234输出会是函数名加源码文件行号比如mydriver_ioctl0x123/0x500这样的信息会转换成/home/user/project/mydriver.c:456。在调试外部模块比如自己写的驱动时使用模块自己的符号表更准确addr2line -f -e /path/to/mydriver.ko ffffffffc0001234注意这里地址要减去模块加载的基址得到模块内偏移后再换算。实际操作中我常用cat /sys/module/mydriver/sections/.text查模块基址然后再减一下稍微有点绕但准确度很高。3.3 用crash工具做离线崩溃转储分析有些崩溃发生在生产环境现场不能停只能通过kdump机制把崩溃时的内存镜像保存下来事后离线分析。这时候crash工具就是主力了。crash工具配合vmlinux和vmcore文件可以像调试器一样查看崩溃时的进程状态、堆栈、内存、全局变量。最常用的命令有bt查看崩溃时所有CPU上的任务栈回溯ps列出系统所有进程状态log查看内核日志缓冲区mod -s module path.ko加载模块符号rd读取指定内存地址的内容struct 结构名 地址按结构体格式化显示内存这套流程对于偶发性、只出现在生产环境、无法本地复现的崩溃问题几乎是唯一出路。我自己遇到过一个小概率的空指针崩溃本地怎么压测都不复现最后就是靠生产环境kdump抓了几次vmcore用crash对比多个镜像才发现是某个罕见的配置组合下全局指针未初始化导致的。配置kdump其实并不复杂。安装kdump-tools配置crashkernel预留内存参数启用服务即可。关键是要给系统预留足够的内存比如crashkernel512M具体大小要根据系统总内存和负载情况调整内存紧张的机器预留太多反而影响业务运行。4. 常见问题速查内核调试中的高频故障内核调试中有些问题出现的频率特别高几乎每个做内核开发或者驱动移植的人都至少碰到过一次。我把这些高频故障整理成了速查表形式方便大家在实际排查时快速对照。故障表现常见原因快速排查思路modprobe报Invalid module formatmodul.ko的vermagic与当前内核不一致modinfo查看vermagic确认内核版本和配置是否一致加载驱动后系统panic或OOM驱动申请的内存过大或申请后未释放检查dmesg中内存分配失败记录配合内存监控定位网卡驱动丢包严重环形缓冲区太小或中断处理太慢ethtool -S查看丢包统计调整ring buffer参数USB设备插入无反应驱动未匹配或设备固件异常dmesg文件系统mount报错磁盘损坏或内核不支持该文件系统类型查看mount命令返回码检查CONFIG_FS相关配置Oops栈回溯不完整编译时未开调试信息或栈被破坏确认CONFIG_DEBUG_INFO使用crash工具进一步分析模块卸载崩溃模块代码在exit路径存在use-after-free使用KASAN或SLUB debug选项排查内存问题GPU驱动报kernel image is invalid驱动与内核版本不匹配或固件加载失败确认固件文件完整性和驱动版本查看dmesg固件加载记录VirtualBox的rc-1908内核模块未正确安装或安全启动阻断重装dkms模块检查signature和lockdown状态这个表里前几项是通用问题后几项就涉及具体场景了。例如“kernel image is invalid”这类报错在GPU计算、深度学习推理、虚拟化场景里经常出现表面上看像是驱动加载问题本质上还是内核与固件/驱动之间版本兼容性和接口契约的问题。我曾经排查过类似的报错最后发现是内核升级后固件加载路径从/lib/firmware下找不到对应版本的固件文件导致设备初始化不完整重新放对固件文件就好了。这类问题的通用排查逻辑是先确认内核版本与驱动版本是否匹配再确认固件文件是否存在且版本正确最后用dmesg和udev日志看设备枚举和固件加载细节。很多看起来诡异的问题拆解到这三步就一目了然了。5. 调试内核模块的几条血泪经验5.1 printk的正确使用姿势printk看起来简单用好了是利器用不好是灾难。踩过几次坑之后我整理了一些自己的习惯。首先控制输出级别。开发阶段可以放开所有打印但进入联调阶段一定要收敛。不然一个热路径上的info级别打印就足以让整个系统性能下降好几个数量级。我做过一个简单测试一个每秒钟调用几十万次的中断处理函数里加一条printk系统吞吐量直接掉了90%以上。其次合理使用pr_debug配合dynamic debug。这比printk更灵活不需要重新编译就能开关。再次注意printk在原子上下文中的使用风险。在自旋锁保护的区域或中断上下文里调用printk可能导致死锁或长时间的调度延迟。虽然现代内核很多场景做了处理但最好还是尽量在锁外面打印。最后生产环境不要乱开printk特别是不要开KERN_DEBUG级别。这不仅是性能问题大量日志还会刷爆日志空间导致关键错误信息被覆盖。5.2 别忽略内核版本和编译选项的影响很多内核模块问题看起来是代码bug实际上是编译环境和运行环境不一致导致的。最常见的坑包括编译模块用的内核头文件版本和运行环境的内核版本不一致导致结构体内存布局不同。内核配置选项不一致例如CONFIG_SMP开启与否会影响spinlock结构体大小。没有使用DKMS手动安装模块后重启后模块丢失或者版本错乱。编译器版本相差过大某些内联函数展开结果不同引起行为差异。所以排查这类问题前我习惯先用uname -a查看运行内核版本再用modinfo验证模块的vermagic最后检查/lib/modules/$(uname -r)/build的软链接是否正确指向内核头文件目录。这三步十几秒就能完成能省掉后面几个小时的折腾。5.3 善用虚拟机环境做隔离验证内核调试很容易把宿主机搞挂尤其是断点、kprobe、崩溃转储这些操作稍不留神就是系统卡死、数据损坏。所以我现在调试内核模块坚持先在虚拟机或者专门的实验环境里验证确认没大问题再上真实机器。虚拟机环境调试有个天然优势可以随时快照、回滚、调日志级别反复几乎零成本。像kprobe、ftrace这些操作在虚拟机上不会产生误伤风险。QEMU/KVM配合serial console输出能把内核启动日志完整保存下来这对调试启动早期的崩溃特别有用因为那个阶段的崩溃根本来不及进系统只能靠串口或者调试器抓。不过虚拟机有个缺点是对硬件相关驱动比如GPU、网卡、USB控制器模拟不完整所以硬件相关的问题最终还得回到真实机器上验证。我的做法是软件和逻辑问题在虚拟机里解决硬件交互问题在真实机器上小范围试两边配合着来。写在最后的调试心法内核调试和普通开发完全是两种思维模式。普通开发是正向的写完代码跑起来就行内核调试是逆向的你面对的是一个运行了数十亿条指令的系统出错点可能早就在几秒前发生了要像侦探一样从各种蛛丝马迹里反推真相。所以我说调试内核的第一原则就是保存现场日志、寄存器、调用栈、内存镜像这些信息一旦丢失就很难再复现。第二原则是缩小范围用dynamic debug、kprobe、ftrace这些工具一步步确定问题所在层而不是对着整个内核大海捞针。这两条原则配合上面那些具体手段大部分内核问题都能在可控时间内解决。