1. 先搞清楚Kernel Panic到底是什么干过Linux运维或者搞过嵌入式开发的朋友十有八九都见过那个让人血压飙升的画面屏幕刷出一堆英文最后一行写着Kernel panic - not syncing然后系统彻底僵死按什么都没反应。我第一次在生产服务器上看到这个是在凌晨两点一台机器跑着核心业务我盯着屏幕上滚动的Call Trace脑子里一片空白。后来踩了好几次坑才算是把这一套分析流程摸透。这篇东西写给谁主要三类人一是Linux运维遇到服务器莫名其妙重启或者死机需要快速定位是硬件问题还是内核问题二是驱动开发或者内核模块开发自己的代码把内核搞挂了需要从panic信息里找到罪魁祸首三是嵌入式方向的朋友板子跑着跑着panic手上又只有串口日志得学会从有限的信息里推理出问题根源。先说一个关键认知Kernel Panic不是你随便就能绕过去的东西。用户态程序崩溃了顶多是个core dump进程死了系统还能跑但内核是操作系统的地基它一旦发现自己已经无法安全地继续执行——比如访问了非法的内存地址、检测到内核数据结构被破坏、发生不可恢复的死锁——就会主动停止整个系统避免把错误状态继续扩散。这个主动停止就是panic。理解了这一点你就明白为什么panic信息里永远包含not syncing这个词内核连文件系统同步都不想做了因为它觉得再做下去也是错的。还有一个容易混淆的概念Oops和Panic的区别。很多新手看到Oops就以为是panic其实不是。Oops是内核捕捉到一个异常比如空指针解引用、非法指令它会打印出寄存器、堆栈和出错指令然后根据错误的严重程度决定是杀掉当前进程继续运行还是直接panic。系统里有个开关叫panic_on_oops默认在大多数发行版里是0意思是Oops发生后只是杀进程系统继续跑如果设成1一旦Oops就直接panic。生产中我建议保持默认别动不动就panic否则一个可恢复的驱动错误就能让整机重启。当然如果你的机器就是被这种杀了进程还继续跑的状态坑过那可以考虑打开让问题尽早暴露。2. 拿到Panic现场日志和控制台输出拆解2.1 怎么把现场信息留下来Panic发生的那一刻系统已经快不行了但你仍然有几条路可以拿到第一手资料。最直接的就是看控制台。物理服务器看显示器或者IPMI的串口重定向虚拟机看VNC嵌入式板卡看串口。重点是你要配置好内核日志的输出级别和输出设备。内核启动参数里加consolettyS0,115200可以把日志打到串口加earlyprintkserial能在非常早的阶段就输出信息。生产服务器如果条件允许强烈建议配一个串口日志服务器把每个节点的串口输出都汇总到一台日志机上这样就算机器panic到完全失去响应日志也已经传到远端了。其次是依赖kdump机制。kdump的原理是系统在启动时单独预留一块内存crashkernelpanic发生后内核跳进这块内存里运行一个精简的捕获内核把崩溃时的内存镜像vmcore保存到磁盘或者通过网络发出去。这样你不仅能看到日志还能拿到一份完整的内存转储可以做非常深度的分析。配置方式是修改/etc/default/grub里的GRUB_CMDLINE_LINUX加上crashkernel512M之类的参数然后安装kexec-tools和kdump服务。具体大小看内存总量一般256M到1G之间如果只有2G内存的机器给256M就行。还有个容易被忽略的点/proc/sys/kernel/panic这个参数。它表示panic后多少秒自动重启默认是0也就是永远挂在那里等你去处理。对无人值守的机器我一般设成10让它panic后十秒自动重启至少先把业务拉起来事后再看crash日志。但这只是应急手段不是分析手段。2.2 读懂Panic输出的关键几行一份典型的panic输出看上去很吓人几百行英文其实真正需要关注的区块就那么几个。我拿最常见的情况举例BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: [ffffffffa03e1020] my_driver_write0x40/0x80 [my_driver] PGD 0 P4D 0 Oops: 0002 [#1] SMP ... RIP: 0010:[ffffffffa03e1020] my_driver_write0x40/0x80 [my_driver] RSP: 0018:ffff88001c3c3d88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88001c5a6000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000010 RDI: ffff88001c5a6000 RBP: ffff88001c3c3de0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88001c3c3e10 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 ... Call Trace: [ffffffffa03e1105] my_driver_ioctl0x85/0xf0 [my_driver] [ffffffff81204b32] do_vfs_ioctl0xa2/0x5c0 [ffffffff81205131] SyS_ioctl0x81/0xa0 [ffffffff81832497] entry_SYSCALL_64_fastpath0x12/0x6a第一行就告诉你问题类型NULL pointer dereference即空指针解引用内核尝试读取地址0x10处的数据。后面跟着的IPInstruction Pointer是出错指令的位置格式是[地址] 函数名偏移量/函数大小 [模块名]这是整个分析里含金量最高的一行。如果函数名是my_driver_write而且带上了模块名[my_driver]说明是驱动模块的代码出事了。RIP那行是64位下的重复信息内容基本一致。Oops: 0002 [#1] SMP里的0002是错误码每一位都有含义2通常表示是读操作还是写操作具体结合页表错误来理解[#1]表示这是第几次Oops如果是[#2]甚至更高说明问题在反复发生可能是不稳定复现的bug。再往下是十几个寄存器的值这个区间的信息量很大。比如上面的例子里RAX: 0000000000000000结合出错指令是访问地址0x10你可以推测出代码大概率是RAX 0x10方式寻址RAX是0于是访问到了0x10。这种推理在汇编级调试时非常常用。Call Trace是函数调用链自下而上是调用顺序最上面一行是最后调用的函数。从这个例子看用户态程序调用了ioctlioctl分派到驱动自己的my_driver_ioctl然后又调用了my_driver_write在write函数里崩了。结合我自己的调试经验看到这种调用链第一反应就是驱动内部对某个数据结构没有做空指针检查直接解引用了。修复方向通常是加NULL检查或者找到为什么那个指针会是空的原因。3. 深挖现场从Oops/panic信息反推根因3.1 用反汇编精确定位出错指令只看函数名和偏移有时不够尤其是驱动代码里大量使用内联函数和宏展开时函数名0x40这个偏移到底对应源码哪一行需要进一步还原。方法是用objdump反汇编然后对着偏移量找。前提是你要有带调试信息的内核镜像或者模块文件。编译内核时加上CONFIG_DEBUG_INFOy模块编译时别strip。这样vmlinux和.ko文件里都带着符号表和调试信息。操作手法是这样的先看模块加载基址因为内核模块是动态加载的IP地址是基址加偏移。RIP显示的ffffffffa03e1020而模块的基址可以通过modinfo或者从panic信息里的模块列表推断。更省事的方法是直接用crash工具或者gdb加载模块符号后反汇编出错函数# 如果有vmlinux和System.map gdb vmlinux (gdb) disassemble my_driver_write在gdb里用disassemble显示函数的汇编代码找到偏移0x40对应的指令。如果编译时带了-g还可以看到每条汇编对应的源码行号。这一步做完基本就能定位到是源码里的哪一行甚至哪一个变量出了问题。在之前的例子中反汇编后你会看到类似于movzbl 0x10(%rax),%eax这样的指令——从RAX0x10处读一个字节RAX恰好是0这就是崩溃点。没有完整调试内核也没关系内核自带的/proc/kallsyms在系统死前可以导出符号表提前备份一份/proc/kallsyms到安全位置出事的时候拿它来对地址至少能还原函数名。3.2 用crash工具分析vmcore如果你配置了kdump拿到了vmcore分析手段就非常丰富了。crash工具是目前主流的vmcore分析工具用法类似gdb但针对内核做了大量封装。最常用的几个命令crash vmlinux vmcore crash bt # 显示所有CPU的堆栈 crash log # 内核日志和dmesg内容一致 crash dis -l ffffffff81001234 # 反汇编指定地址并尽量标注源码行 crash struct task_struct ffff88001c5a6000 # 查看指定结构体内容 crash ps # 查看崩溃时进程列表 crash mod -S # 加载模块符号 crash rd -a # 读取指定内存地址我印象很深的一次分析vmcore里bt显示CPU0在ext4_journal_start_sb里CPU1在schedule里两个CPU的堆栈一直停在那里不动最后在log里发现了BUG: soft lockup - CPU#1 stuck for 22s!。这个排查思路就完全不一样了——这不是内存破坏是软锁死即某个CPU长时间关中断或者在不可调度的上下文里死循环导致内核的看门狗机制触发panic。通过crash查看CPU1的堆栈和寄存器最后定位到是网卡驱动的某个加锁路径在极端流量下出现了死循环重试。这种问题在普通日志里很难判断但有了vmcore所有状态一目了然。panic分析里有个很重要的原则不要只看崩溃的CPU其他CPU的堆栈同样有价值。很多时候崩溃只是一个受害者真正的凶手在另一个CPU上——比如它持有一把锁不释放别的CPU在等锁的时候触发了hung task检测进而panic。crash的bt -a命令能同时打印所有CPU的堆栈这个一定要养成习惯。3.3 从vmcore里找出凶手进程有时候panic信息和当前进程没有直接关系尤其是内存耗尽或者中断上下文导致的panic。这时候需要用ps命令看崩溃瞬间系统里有哪些进程用foreach bt把系统中所有进程的堆栈都拉出来。如果发现某个进程卡在内存分配路径上或者某个进程的虚拟内存区域VMA出现了异常那它很可能就是造成问题的元凶。还有一类很隐蔽的问题内存被踩memory corruption。比如某个驱动越界写坏了一个slab对象但崩的时候不一定在那个驱动里可能是在页面回收路径上表现为BUG: Bad page state in process或者page:ffffea000... count:-1 mapcount:0 mapping:...。遇到这种光看崩溃现场是不够的要配合CONFIG_DEBUG_PAGEALLOC、CONFIG_SLUB_DEBUG这些内核调试选项让slab分配器在对象释放和分配时做完整性校验这样能在踩内存的行为刚发生时就把问题暴露出来而不是等它扩散成偶发的panic。开这些选项会带来性能开销生产环境实在没法开那就只能在测试环境复现问题了。4. 高频Panic场景排查实录4.1 空指针解引用最常见也最好认这类panic的日志特征非常明显BUG: unable to handle kernel NULL pointer dereference或者64位下是BUG: unable to handle page fault for address: 0000000000000000。原因不外乎三种一是内核API返回了错误指针但调用方没检查就用了二是设备驱动在模块卸载后还有异步回调访问了已释放的私有数据三是某些竞态条件下共享指针被别的路径置空了当前线程恰好来访问。排查套路是固定的先看IP确定崩在哪个函数再看寄存器推测寻址方式然后从Call Trace往上追溯找到这个空指针是什么时候传进来的源头在哪里。如果用ftrace能抓到函数调用历史就更好了trace-cmd record -p function_graph -l my_driver_*可以只跟踪你自己的驱动函数开销可控在复现问题时能提供非常清晰的调用时间线。实战里这类问题的修复往往是一行NULL检查的事但难的是找到那个这个指针理论上不可能是空啊的路径。4.2 内核堆栈溢出和内存分配失败Kernel panic - not syncing: Out of memory and no killable processes这类panic是内存管理子系统触发的最后手段——系统内存耗尽而且没有可以杀掉的用户态进程来回收内存只能panic。常见于Cgroup内存限制配置错误、某个进程疯狂申请内存、或者内存泄漏。注意区分用户态OOM通常触发OOM Killer挑一个进程杀掉就继续运行内核态的Out of memory出现在panic前面意味着连内核自己的数据结构都分配不出来了比如kmalloc失败且调用方没有处理错误路径。还有一种是vmalloc地址空间耗尽vmalloc: allocation failure之后系统进入不稳定状态最终panic。排查时用dmesg看OOM发生之前有没有oom_kill的记录用/sys/fs/cgroup/memory/下的统计看是不是被某个cgroup限制住了。内存泄漏方向的排查可以用slabtop看slab缓存是否异常增长用/proc/meminfo对比Slab字段的历史曲线。我自己踩过最坑的一种情况是某个内核模块每次操作都分配一小块内存但忘记释放泄漏速度极慢两周后系统才因为内存耗尽panic。这种问题只能在测试环境长时间监控/proc/slabinfo对比各个模块的分配计数来发现。4.3 死锁与RCU Stall引发的panic遇到INFO: rcu_sched detected stalls on CPUs/tasks或者BUG: soft lockup说明CPU长时间无法进行调度或者RCU宽限期无法推进内核的检测机制认为系统已经卡死于是触发主动panic来打破僵局。这类问题背后的典型原因是中断上下文里调用了一个可能睡眠的函数比如mutex_lock造成死锁或者某个驱动的自旋锁在关中断的情况下被长时间持有导致其他CPU饥饿。这类型问题用静态分析很难发现建议在测试阶段就开启CONFIG_PROVE_LOCKINGlockdep它能在锁的获取/释放顺序不对时立刻打印warning而不是等到线上死锁。如果线上已经出了问题vmcore里的foreach bt能够看到多个CPU互相等待锁的堆栈用lock信息对比就能还原出死锁环。还有一个排查技巧把serial console配置上用sysrq-trigger在系统假死但还没完全panic的时候手动让内核打印所有任务的堆栈这个操作有时候比等panic更好使因为它是活体解剖能抓到更多现场。4.4 硬件相关与驱动加载导致的panicunable to load the kernel module nvidia.ko这类问题虽然不是panic但在显卡驱动、硬件加速场景下非常普遍——本质是模块签名校验失败、内核版本头文件不匹配、或者硬件不支持导致模块初始化失败。而比这更严重的是模块init函数直接引发panic比如设备驱动在probe阶段访问了硬件不存在的MMIO地址触发总线错误。这类panic的日志里往往能看到Unable to handle kernel paging request at virtual address同时地址值非常奇怪不是0而是一个固定的高位地址。排查手段上先确认加载模块时用的内核头文件版本和当前运行内核完全一致modinfo nvidia.ko | grep vermagic对比uname -r。如果是自己写的驱动要检查request_mem_region和ioremap是否都成功失败后有没有直接返回错误码而不是继续往下走。我遇到过的情况是某款PCIe设备在特定主板上只有三个MMIO BAR驱动却傻乎乎地访问了第四个结果每次加载都panic。这种问题从日志的地址就能看出来——访问的地址不在硬件实际映射的范围内结合lspci -vvv核对BAR区间很快就能定位。5. 实战复盘一次完整的Panic定位过程为了让你把前面的内容串起来我复盘一次真实的排查经历。一台测试服务器跑着一个自己写的字符设备驱动在高频读写压力下系统大概每两三个小时panic一次毫无规律。现象是ssh断开、控制台刷屏最后一行是Kernel panic - not syncing: Fatal exception。我先通过console拿到了完整的panic输出关键信息是BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [ffffffffc0791088] mydev_write0x88/0x140 [mydev]出错函数是mydev_write偏移0x88。我用反汇编把这段代码拉出来看到是mov %rbx,0x8(%rax)——向RAX8写入RBX的值。寄存器的快照显示RAX为0所以写入地址是0x8触发了空指针访问。问题很清晰mydev_write里取到了一个空的私有数据结构指针但没有检查就直接写。到这里修复看起来很简单加个NULL检查。但我没有急着改代码因为更要紧的问题是这个私有数据结构的指针为什么是空的驱动在open时用kzalloc分配了它挂到filp-private_data上正常情况下不应该为空。我用了第4节提到的排查思路先看是不是设备在写入前没被正常open——检查了用户态测试程序的流程确实每次读写前都先open。那问题就出在竞态上close的时候代码把private_data设置了NULL并释放了内存但如果此时另一个线程还握着一个旧的文件描述符在做write就会出现访问已释放/已置空数据的场景。看代码就明白了close的清理函数里释放完私有数据后又把filp-private_data置NULL这个操作和write读取private_data是两个不同的临界区中间没有保护。解决方法是把private_data的读写都纳入互斥锁保护或者在close里不置NULL而是让write先获取锁再检查。这活儿看着简单但不把竞态分析清楚加了NULL检查也只是把panic变成了静默的功能异常更难抓。这类问题想稳定复现还有个工具很管用CONFIG_KCSAN内核数据竞争检测器。它能在运行时检测到不加锁的并发读写虽然有一定性能开销但在测试环境跑一遍压力测试能把竞态点直接报出来。如果项目里能开强烈建议开上跑一轮回归。6. 防患于未然减少Panic的工程化手段6.1 内核配置与启动参数上的预防线上环境的内核在稳定压倒一切的前提下尽量开启CONFIG_SLUB_DEBUG、CONFIG_DEBUG_SPINLOCK、CONFIG_DEBUG_MUTEXES、CONFIG_PROVE_LOCKING。这些选项的开销在生产上可以接受但对尽早暴露问题帮助极大。另外CONFIG_PANIC_ON_OOPS和CONFIG_PANIC_TIMEOUT这两个配置编译时就能决定行为我通常在生产环境禁用panic on oops测试环境开启并搭配kdump让问题一发生就留下完整现场。启动参数里值得关注的是nmi_watchdog1和softlockup_panic1、hung_task_panic1。前面两个让锁死检测到之后就panic而不是干等后面那个让长期阻塞的任务触发panic。配合kdump能把机器卡死这种最难排查的问题变成有明确vmcore可分析的问题。还有mcepanic如果你的服务器有硬件报错Machine Check Exception让它直接panic重启有时候比带病运行更安全毕竟内存数据已经不可信了。6.2 日常巡检与压测习惯经历过几次深夜panic之后我自己养成了这么几个习惯。一是给所有生产内核开启kdump并且定期做注入测试——用echo c /proc/sysrq-trigger触发一次模拟panic验证crashkernel配置和vmcore落盘是否正常这个测试半年做一次确保关键时刻工具链是好的。二是新驱动或者新内核上线前必须在测试环境跑满72小时的压测包括CPU、内存、磁盘IO、网络并发并且全程开着lockdep和KCSAN。三是把/proc/kallsyms、dmesg、模块版本信息、内核config都定期归档panic分析最怕的就是你看看这个地址是哪个函数的时候手边连份符号表都没有。还有一个小技巧很多老运维都在用系统起好后立刻把/proc/iomem、/proc/interrupts、lspci -vvv、dmidecode这些硬件资源信息导出一份存好。硬件层面的panic比如AER报错、PCIe链路退化分析的时候这些基线数据能帮你快速判断硬件配置是否异常。6.3 从panic日志中挖掘系统性的线索最后说一个容易被忽略的点panic日志里除了崩溃点本身周围的信息反而更能说明问题。比如panic前几行如果有大量blocked for more than 120 seconds说明系统早就进入了某种半死不活的状态panic只是压垮骆驼的最后一根稻草。又比如panic前出现page allocation failure那根源很可能在内存碎片或泄漏而不是崩溃点本身。所以拿到一份panic日志我会先从头到尾通读一遍把时间线上所有warning、error、failed标记出来再结合崩溃点一起分析。这种整体视角在分布式或虚拟化环境里尤其重要——物理机上跑着十几个虚拟机一个宿主机panic可能只是某个虚拟机疯狂触发内核陷阱导致的连锁反应光盯着崩溃虚拟机看是解决不了问题的。分析Linux内核panic这件事入门门槛不高但深度可以非常深。从第一眼看到panic信息时的慌乱到后来能冷静地反汇编、看寄存器、拉堆栈再到能通过vmcore还原整个现场每一步的经验都是拿实际踩坑换来的。这套方法论在工作里一次又一次帮我把看不出来问题变成定位到具体一行代码如果你也经常处理这类问题建议把kdump和crash这套流程在自己的环境里完整搭一遍别等真出事了再临时抱佛脚。