一文教你用Kdump分析内核崩溃原因（实例演示 ~）
本文主要介绍kdump服务和crash的使用，并结合一个简单的实例演示如何分析内核崩溃的原因。本文基于Linux kernel 4.19， 体系结构为aarch64。
kdump概述
克转储
kdump 是一种基于 kexec 的内核崩溃转储机制，用来捕获内核 crash（内核崩溃）的时候产生的 crash dump。当内核产生错误时，kdump会将内存导出为vmcore保存到磁盘。
kdump流程
当系统崩溃时，kdump 使用 kexec 启动到第二个内核。第二个内核通常叫做捕获内核，以很小内存启动以捕获转储镜像。第一个内核启动时会保留一段内存给kdump用。
kdump的配置
系统启动时为crashkernel保留内存
可以在内核命令行中加入如下参数：crashkernel=size[@offset]。保留内存是否预留成功，可以通过cat /proc/meminfo查看。。
cat /proc/meminfo |格雷普崩溃
安装kexec-toools
yum install kexec-tools
kexec-tool推荐使用rpm方式安装，使用时需要和内核版本配套。
启动kdump服务
systemctl start kdump.service // 启动kdump服务 service kdump status // 查看kdump状态
testkdump是否可以正常转储
echo c > /proc/sysrq-trigger
如果没有问题，系统会自动重启，重启后可以看到在/var/crash/目录下生成了coredump文件。
【文章福利】小编推荐自己的Linux内核技术交流群:【891587639】整理了一些个人觉得比较好的学习书籍、视频资料共享在群文件里面，有需要的可以自行添加哦！！！（含视频教程、电子书、实战项目及代码)
qemu使用kdump
我们经常会使用qemu去启动虚拟机。qemu启动的内核发生错误也可以用kdump生成vmcore文件。
首先先将qemu的panic重启关闭，防止coredump的时候发生了重启
echo 0 > /proc/sys/kernel/panic
触发内核崩溃
echo c > /proc/sysrq-trigger
kernel panic后，使得qemu进入monitor模式
ctrl + A， ---> c， qemu进入monitor模式
进入monitor模式后，进行coredump
dump-guest-memory -z xxx-vmcore
如下图所示，成功在qemu 的kernel panic后，获得了coredump文件。
使用crash分析内核奔溃转储文件
在内核奔溃后，如果部署了kdump， 会在/var/crash目录中找到vmcore转储文件，vmcore文件可以配合crash工具进行分析。
crash的版本要和内核的版本保持一致， 比如上面成功dump了qemu arm64的coredump文件，就需要配套的arm64的crash工具进行分析，否则会报兼容性错误。
编译 ARM64 崩溃工具：
下载：https://github.com/crash-utility/crash/releases编译安装： $ tar -xf 崩溃-7.2.8.tar.gz $ CD 崩溃-7.2.8/ $ 使目标=arm64
安装完成后，使用crash工具分析vmcore文件， vmlinux在编译内核时会在根目录下生成。
崩溃 VMcore VMLinux
crash常用命令
bt： 查看函数调用栈
log： 查看内核dmesg日志
struct： 查看数据结构
struct -o [struct] ： 显示结构体中成员的偏移 struct [struct] [address] ： 显示对应地址结构体的值 [结构][地址] ：简化形式显示对应地址结构体的值 [结构][地址] -xo： 打印结构体定义和大小 [struct].member[address]： 显示某个成员的值
rd： 读取内存内容
rd [addr] [len]： 查看指定地址，长度为len的内存 rd -S [addr][len]： 尝试将地址转换为对应的符号 rd [addr] -e [addr] ： 查看指定内存区域内容
dis： 进行返汇编，查看对应地址的代码逻辑
ps： 查看线程状态
ps -p [pid]： 显示进程父子关系 ps -t [pid]： 显示进程运行时间
kmem： 查看内核内存使用情况
kmem -i： 查看内存整体使用情况 kmem -s： 查看slab使用情况 kmem [addr]： 搜索地址所属的内存结构
更多其它命令通过help查看
内核panic实例
内核访问空指针产生panic。
驱动制作
编写一个驱动，构造一个内核模块访问空指针的异常，演示如何使用crash分析内核奔溃的原因。
将编好的驱动打包进根文件系统， 启动后插入内核模块。
panic 分析
内核的call trace如上图所示， 将对应的文件反汇编，找到问题出现对应的代码。
aarch64-linux-gnu-objdump -S panic-kernel.o > test.txt
截取部分反汇编如下：
从汇编代码可以看出， panic_foo函数的参数（x0）最终保存在x19寄存器。我们现在想要知道出现问题时，代码走的是哪一个分支。
配合crash进行分析，先导入模块符号表：
使用crash 查看出问题时结构体的值，确认函数走的是哪个分支。函数的参数是x19：
从打印的之来看，head成员的值为10， 可以确定代码走的是哪一个分支。
再结合之前的反汇编代码， 出错的位置在pc： panic_foo +0x54。pc保存的是栈顶指针，lr保存的是函数返回的地址（x30）
偏移54的位置是把w0的值保存到x21， 而x21的地址是0。w0的值是mov w0， 0xffff直接赋值得来的。所以这里是将0xffff直接写到0地址导致的问题。
综上如上信息，结合实际的代码，最终找到问题的原因。
原文作者：人人都是极客
