用crash调试linux kernel
- 格式:pdf
- 大小:512.53 KB
- 文档页数:14
当主机crash后,会在这个目录下生成vmcore,也就是dump,如何分析这个dump来定位宕机的原因呢?可以执行crash vmlinux /var/crash/127.0.0.1-2014-06-22-16:08:36 来进入分析模式(vnlinux这里要指定的)他会报错,原因应该是缺乏kernel-debuginfo包,我们安装下后再尝试:要想crash可以分析core-dump,必须要安装这三个包:安装完后,我们可以利用find / -name vmlinux上面的crash爆出了:报错,这是由于kernel-debuginfo-common-x86_64包的版本和本机内核版本不一致照成的。
(说下:要想使用crash,只要保证debuginfo的版本和你要分析的core的内核版本本机的kernel版本三者的版本必须一样,任意一个不一致都会导致不能分析dump)##选择包和版本#再选择show debug package找到debug包 下载就可以了----------------------------------------然后安装一下:#安装包开始++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++至于我们怎么知道coredump的内核版本,可以cd /var/crash/127.0.0.1---------/然后执行strings vmcore |grep 'OSRELEASE'可以显示出vmcore的内核版本顺便附一下内核版本和系统版本的对应关系CentOS 6.0/RHEL6 Update 0 -------------------> 2.6.32-71CentOS 6.1/RHEL6 Update 1 -------------------> 2.6.32-131CentOS 6.2/RHEL6 Update 2 -------------------> 2.6.32-220CentOS 6.3/RHEL6 Update 3 -------------------> 2.6.32-279CentOS 6.4/RHEL6 Update 4 -------------------> 2.6.32-358CentOS 6.5/RHEL6 Update 5 -------------------> 2.6.32-431CentOS 6.6/RHEL6 Update 6 -------------------> 2.6.32-504++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ #后再分析下dump可以进crash模式了。
crashkernel参数(原创实用版)目录1.介绍 crashkernel 参数2.crashkernel 参数的作用3.使用 crashkernel 参数的方法4.crashkernel 参数的示例5.结论正文1.介绍 crashkernel 参数crashkernel 参数是 Linux 内核中的一个重要参数,主要用于在系统崩溃时进行内核转储,以便于对系统崩溃的原因进行分析和调试。
crashkernel 参数通常在系统启动时由内核自动设置,也可以通过手动编辑内核配置文件进行设置。
2.crashkernel 参数的作用crashkernel 参数的主要作用是在系统发生异常时,将内核的当前状态保存到一个文件中,以便于系统管理员或开发人员进行分析。
通过分析crashkernel 参数保存的内核状态,可以找到系统崩溃的原因,进而对系统进行调试和优化。
3.使用 crashkernel 参数的方法要使用 crashkernel 参数,首先需要确保系统内核已经启用了crashkernel 支持。
接下来,可以通过以下两种方法使用 crashkernel 参数:(1)使用命令行工具:可以使用“crash”命令将 crashkernel 参数保存到一个文件中。
例如:```crash /path/to/crashkernel```(2)手动编辑内核配置文件:可以手动编辑内核配置文件(通常位于 /usr/src/linux/.config 或 /usr/src/linux-xx.xx/.config),将CRASH_DUMP_ON_ZERO_PANIC设置为y,并配置一个用于存储crashkernel 文件的路径。
例如:```CONFIG_CRASH_DUMP_ON_ZERO_PANIC=yCONFIG_CRASH_DUMP_DIR=/path/to/crashdumps```4.crashkernel 参数的示例以下是一个 crashkernel 参数的示例:```$ crash /path/to/crashkernel```上述命令将把系统当前的状态保存到/path/to/crashkernel文件中。
当主机crash后,会在这个目录下生成vmcore,也就是dump,如何分析这个dump来定位宕机的原因呢?可以执行crash vmlinux /var/crash/127.0.0.1-2014-06-22-16:08:36 来进入分析模式(vnlinux这里要指定的)他会报错,原因应该是缺乏kernel-debuginfo包,我们安装下后再尝试:要想crash可以分析core-dump,必须要安装这三个包:安装完后,我们可以利用find / -name vmlinux上面的crash爆出了:报错,这是由于kernel-debuginfo-common-x86_64包的版本和本机内核版本不一致照成的。
(说下:要想使用crash,只要保证debuginfo的版本和你要分析的core的内核版本本机的kernel版本三者的版本必须一样,任意一个不一致都会导致不能分析dump)##选择包和版本#再选择show debug package找到debug包 下载就可以了----------------------------------------然后安装一下:#安装包开始++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++至于我们怎么知道coredump的内核版本,可以cd /var/crash/127.0.0.1---------/然后执行strings vmcore |grep 'OSRELEASE'可以显示出vmcore的内核版本顺便附一下内核版本和系统版本的对应关系CentOS 6.0/RHEL6 Update 0 -------------------> 2.6.32-71CentOS 6.1/RHEL6 Update 1 -------------------> 2.6.32-131CentOS 6.2/RHEL6 Update 2 -------------------> 2.6.32-220CentOS 6.3/RHEL6 Update 3 -------------------> 2.6.32-279CentOS 6.4/RHEL6 Update 4 -------------------> 2.6.32-358CentOS 6.5/RHEL6 Update 5 -------------------> 2.6.32-431CentOS 6.6/RHEL6 Update 6 -------------------> 2.6.32-504++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ #后再分析下dump可以进crash模式了。
什么是 crash如前文所述,当 linux 系统内核发生崩溃的时候,可以通过 kdump 等方式收集内核崩溃之前的内存,生成一个转储文件 vmcore。
内核开发者通过分析该 vmcore 文件就可以诊断出内核崩溃的原因,从而进行操作系统的代码改进。
那么 crash 就是一个被广泛使用的内核崩溃转储文件分析工具,掌握 crash 的使用技巧,对于定位问题有着十分重要的作用。
回页首使用 crash 的先决条件由于 crash 用于调试内核崩溃的转储文件,因此使用 crash 需要依赖如下条件:1. kernel 映像文件 vmlinux 在编译的时候必须指定了 -g 参数,即带有调试信息。
2. 需要有一个内存崩溃转储文件(例如 vmcore),或者可以通过 /dev/mem 或/dev/crash 访问的实时系统内存。
如果 crash 命令行没有指定转储文件,则 crash 默认使用实时系统内存,这时需要 root 权限。
3. crash 支持的平台处理器包括:x86, x86_64, ia64, ppc64, arm, s390, s390x ( 也有部分 crash 版本支持 Alpha 和 32-bit PowerPC,但是对于这两种平台的支持不保证长期维护 )。
4. crash 支持 2.2.5-15(含)以后的 Linux 内核版本。
随着 Linux 内核的更新,crash 也在不断升级以适应新的内核。
回页首crash 安装指南要想使用 crash 调试内核转储文件,需要安装 crash 工具和内核调试信息包。
不同的发行版安装包名称略有差异,这里仅列出 RHEL 和 SLES 发行版对应的安装包名称如下:表 1. crash 工具和内核调试包系统版本crash 工具名称内核调试信息包RHEL6.2 crash kernel-debuginfo-commonkernel-debuginfoSLES11SP2 crash kernel-default-debuginfokernel-ppc64-debuginfo以 RHEL 为例,安装 crash 及内核调试信息包的步骤如下:rpm -ivh crash-5.1.8-1.el6.ppc64.rpmrpm -ivh kernel-debuginfo-common-ppc64-2.6.32-220.el6.ppc64.rpmrpm -ivh kernel-debuginfo-2.6.32-220.el6.ppc64.rpm回页首启动 crash启动参数说明使用 crash 调试转储文件,需要在命令行输入两个参数:debug kernel 和 dump file,其中 dump file 是内核转储文件的名称,debug kernel 是由内核调试信息包安装的,不同的发行版名称略有不同,以 RHEL 和 SLES 为例:RHEL6.2:/usr/lib/debug/lib/modules/2.6.32-220.el6.ppc64/vmlinuxSLES11SP2:/usr/lib/debug/boot/vmlinux-3.0.13-0.27-ppc64.debug使用 crash -h 或 man crash 可以查看 crash 支持的一系列选项,这里仅以常用的选项为例说明如下:-h:打印帮助信息-d:设置调试级别-S:使用 /boot/System.map 作为默认的映射文件-s:不显示版本、初始调试信息等,直接进入命令行-i file:启动之后自动运行 file 中的命令,再接受用户输入crash 报告分析crash 命令启动后,会产生一个转储文件的分析报告摘要,如下图所示。
crash的用法
Crash是一个开源的实时系统监控工具,可以分析和跟踪Linux内核崩溃、Oops、Panic等事件,以及收集系统运行状态信息。
使用 Crash 可以快速定位问题,如果能够成功捕捉到系统崩溃的瞬间,就可以取得最接近问题发生前后的系统状态,从而定位和解决问题。
使用 Crash 的步骤比较简单:
1. 使用“crash”命令创建 crash 调试会话,并选择要调试的内核版本;
2. 使用“bt”命令打印出堆栈回溯,以便了解系统在崩溃之前的状态;
3. 使用“info”命令查看内核变量,以便分析崩溃原因;
4. 使用“set”命令设置断点,以便在崩溃之前进行调试;
5. 退出 crash 调试会话,保存 dump 文件,以便日后分析和研究。
Crash使⽤参考整理⾃man 8 crash1、简介Crash⼯具可以⽤来分析⼀个正在运⾏的内核,也可以⽤来分析⼀个内核的crash dump⽂件,这⾥说的是内核代码异常产⽣的crash dump⽂件,不是应⽤层程序运⾏异常产⽣的core dump⽂件,它⽀持分析由netdump, diskdump, LKCD, kdump, xen‐dump 或者 kvmdump ⼯具产⽣的crash dump⽂件。
它整合了SVR4 UNIX crash的⼯具和GDB调试器,因⽽具有源码级别调试能⼒。
Crash⼯具可以⽤来分析内核的调⽤堆栈,内核源码的反汇编,内核数据结构和变量的格式化展⽰等等,另外Crash也可以传递⼀些GDB命令来执⾏。
在初始化的过程中,$HOME/.crashrc ⽂件中的命令和当前⽬录下的./.crashrc⽂件中的命令将会被执⾏。
Crash⼯具后向兼容,当内核版本变化导致Crash⼯具更新后后仍然会兼容以前的内核版本。
2、启动命令⾏crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS] (⽤来分析dumpfile⽂件)crash [OPTION]... [NAMELIST] (⽤来分析正在运⾏的系统)NAMELIST:这个是未压缩的内核镜像⽂件(vmlinux)的路径,在⽤来分析dumpfile⽂件的时候也可以使⽤gzip或者bzip2压缩后的vmlinux⽂件。
MEMORY-IMAGE[@ADDRESS]:由netdump, diskdump, LKCD, kdump, xen‐dump 或者 kvmdump ⼯具产⽣的crash dump⽂件的路径,如果运⾏Crash⼯具没有输⼊这个参数的话,那么Crash⼯具将会⽤来分析正在运⾏的linux内核,分析正在运⾏的内核需要访问系统的RAM,⼀般是需要root权限的。
分析live system的时候,默认情况下/dev/crash将会被使⽤,如果这个⽂件不存在,然后会使⽤/dev/mem,但是如果kernel被配置为CONFIG_STRICT_DEVMEM,那么/proc/kcore将会被使⽤,也可以显式的指定/dev/crash、/dev/mem 、 /proc/kcore。
当主机crash后,会在这个目录下生成vmcore,也就是dump,如何分析这个dump来定位宕机的原因呢?可以执行crash vmlinux /var/crash/127.0.0.1-2014-06-22-16:08:36 来进入分析模式(vnlinux这里要指定的)他会报错,原因应该是缺乏kernel-debuginfo包,我们安装下后再尝试:要想crash可以分析core-dump,必须要安装这三个包:安装完后,我们可以利用find / -name vmlinux上面的crash爆出了:报错,这是由于kernel-debuginfo-common-x86_64包的版本和本机内核版本不一致照成的。
(说下:要想使用crash,只要保证debuginfo的版本和你要分析的core的内核版本本机的kernel版本三者的版本必须一样,任意一个不一致都会导致不能分析dump)##选择包和版本#再选择show debug package找到debug包 下载就可以了----------------------------------------然后安装一下:#安装包开始++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++至于我们怎么知道coredump的内核版本,可以cd /var/crash/127.0.0.1---------/然后执行strings vmcore |grep 'OSRELEASE'可以显示出vmcore的内核版本顺便附一下内核版本和系统版本的对应关系CentOS 6.0/RHEL6 Update 0 -------------------> 2.6.32-71CentOS 6.1/RHEL6 Update 1 -------------------> 2.6.32-131CentOS 6.2/RHEL6 Update 2 -------------------> 2.6.32-220CentOS 6.3/RHEL6 Update 3 -------------------> 2.6.32-279CentOS 6.4/RHEL6 Update 4 -------------------> 2.6.32-358CentOS 6.5/RHEL6 Update 5 -------------------> 2.6.32-431CentOS 6.6/RHEL6 Update 6 -------------------> 2.6.32-504++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ #后再分析下dump可以进crash模式了。
linux kernel assert用法在Linux内核开发中,assert(断言)是一种常见的调试工具。
它用于在程序中检查某个条件是否满足,如果不满足,则触发断言失败,中止程序的执行并显示错误消息。
本文将介绍Linux内核中assert的用法及其在开发中的重要性。
在Linux内核的源代码中,我们经常可以见到以下形式的assert语句:```c#define assert(expr) \do { \if (!(expr)) { \printk(KERN_ERR "Assertion failed: %s, file: %s, line: %d\n", #expr,__FILE__, __LINE__); \BUG(); \} \} while (0)```这里的`assert(expr)`是一个宏定义,它的作用是检查表达式`expr`是否为真。
如果`expr`为假,`assert`会输出错误消息,包括失败的表达式、所在的文件和行号,并且通过调用`BUG()`宏中止程序的执行。
使用assert语句的好处是帮助开发人员快速定位出错的地方,尤其是在调试和测试阶段。
当某个条件不满足时,断言失败会立即停止程序的执行,这样可以防止错误继续传播,并提供了一些关键信息,例如出错的表达式、文件名和行号等。
这些信息可以帮助开发人员迅速定位错误位置,加快错误修复的速度。
而在发布时,通常会使用编译选项来禁用assert语句,以提高代码的执行效率。
对C语言编译器来说,可以使用`-DNDEBUG`选项来取消定义`NDEBUG`宏,这会导致所有的assert语句在编译时被移除。
这样发布版本的代码将不会包含assert语句,从而提高代码的性能。
在Linux内核开发中,assert语句通常用于以下几种情况:1. 参数检查:在函数的开头,使用assert语句检查传入的参数是否合法。
它可以确保函数在被调用时,参数的值满足特定的条件,避免出现不可预料的错误。
Linuxkernel调试⽅法及⼯具Linux内核调试的⽅式以及⼯具集锦CSDN GitHubLinux内核调试的⽅式以及⼯具集锦 LDD-LinuxDeviceDrivers/study/debug"调试难度本来就是写代码的两倍. 因此, 如果你写代码的时候聪明⽤尽, 根据定义, 你就没有能耐去调试它了."--Brian Kernighan121 内核调试以及⼯具总结内核总是那么捉摸不透, 内核也会犯错, 但是调试却不能像⽤户空间程序那样, 为此内核开发者为我们提供了⼀系列的⼯具和系统来⽀持内核的调试.内核的调试, 其本质是内核空间与⽤户空间的数据交换, 内核开发者们提供了多样的形式来完成这⼀功能.⼯具描述debugfs等⽂件系统提供了 procfs, sysfs, debugfs以及 relayfs 来与⽤户空间进⾏数据交互, 尤其是 debugfs, 这是内核开发者们实现的专门⽤来调试的⽂件系统接⼝. 其他的⼯具或者接⼝, 多数都依赖于 debugfs.printk 强⼤的输出系统, 没有什么逻辑上的bug是⽤PRINT解决不了的ftrace以及其前端⼯具trace-cmd等内核提供了 ftrace ⼯具来实现检查点, 事件等的检测, 这⼀框架依赖于 debugfs, 他在 debugfs 中的 tracing ⼦系统中为⽤户提供了丰富的操作接⼝, 我们可以通过该系统对内核实现检测和分析. 功能虽然强⼤, 但是其操作并不是很简单, 因此使⽤者们为实现了 trace-cmd 等前端⼯具, 简化了 ftrace 的使⽤.kprobe以及更强⼤的systemtap 内核中实现的 krpobe 通过类似与代码劫持⼀样的技巧, 在内核的代码或者函数执⾏前后, 强制加上某些调试信息, 可以很巧妙的完成调试⼯作, 这是⼀项先进的调试技术, 但是仍然有觉得它不够好, 劫持代码需要⽤驱动的⽅式编译并加载, 能不能通过脚本的⽅式⾃动⽣成劫持代码并⾃动加载和收集数据, 于是systemtap 出现了. 通过 systemtap ⽤户只需要编写脚本, 就可以完成调试并动态分析内核kgdb && kgtp KGDB 是⼤名⿍⿍的内核调试⼯具, KGTP则通过驱动的⽅式强化了 gdb的功能, 诸如tracepoint, 打印内核变量等.perf erf Event是⼀款随 inux内核代码⼀同发布和维护的性能诊断⼯具, 核社区维护和发展. Perf 不仅可以⽤于应⽤程序的性能统计分析, 也可以应⽤于内核代码的性能统计和分析. 得益于其优秀的体系结构设计, 越来越多的新功能被加⼊ Perf, 使其已经成为⼀个多功能的性能统计⼯具集LTTng LTTng 是⼀个 Linux 平台开源的跟踪⼯具, 是⼀套软件组件, 可允许跟踪 Linux 内核和⽤户程序, 并控制跟踪会话(开始/停⽌跟踪、启动/停⽌事件等等).2 ⽤户空间与内核空间数据交换的⽂件系统内核中有三个常⽤的伪⽂件系统: procfs, debugfs和sysfs.⽂件系统描述procfs The proc filesystem is a pseudo-filesystem which provides an interface to kernel data structures.sysfs The filesystem for exporting kernel objects.debugfs Debugfs exists as a simple way for kernel developers to make information available to user space.relayfs A significantly streamlined version of relayfs was recently accepted into the -mm kernel tree.它们都⽤于Linux内核和⽤户空间的数据交换, 但是适⽤的场景有所差异:procfs 历史最早, 最初就是⽤来跟内核交互的唯⼀⽅式, ⽤来获取处理器、内存、设备驱动、进程等各种信息.sysfs 跟 kobject 框架紧密联系, ⽽ kobject 是为设备驱动模型⽽存在的, 所以 sysfs 是为设备驱动服务的.debugfs 从名字来看就是为 debug ⽽⽣, 所以更加灵活.relayfs 是⼀个快速的转发 (relay) 数据的⽂件系统, 它以其功能⽽得名. 它为那些需要从内核空间转发⼤量数据到⽤户空间的⼯具和应⽤提供了快速有效的转发机制.在 Linux 下⽤户空间与内核空间数据交换的⽅式, 第 2 部分: procfs、seq_file、debugfs和relayfsLinux ⽂件系统:procfs, sysfs, debugfs ⽤法简介2.1 procfs⽂件系统ProcFs 介绍`procfs 是⽐较⽼的⼀种⽤户态与内核态的数据交换⽅式, 内核的很多数据都是通过这种⽅式出⼝给⽤户的, 内核的很多参数也是通过这种⽅式来让⽤户⽅便设置的. 除了 sysctl 出⼝到 /proc 下的参数, procfs 提供的⼤部分内核参数是只读的. 实际上, 很多应⽤严重地依赖于procfs, 因此它⼏乎是必不可少的组件. 前⾯部分的⼏个例⼦实际上已经使⽤它来出⼝内核数据, 但是并没有讲解如何使⽤, 本节将讲解如何使⽤procfs.参考资料⽤户空间与内核空间数据交换的⽅式(2)——procfs2.2 sysfs⽂件系统内核⼦系统或设备驱动可以直接编译到内核, 也可以编译成模块, 编译到内核, 使⽤前⼀节介绍的⽅法通过内核启动参数来向它们传递参数, 如果编译成模块, 则可以通过命令⾏在插⼊模块时传递参数, 或者在运⾏时, 通过 sysfs 来设置或读取模块数据.Sysfs 是⼀个基于内存的⽂件系统, 实际上它基于ramfs, sysfs 提供了⼀种把内核数据结构, 它们的属性以及属性与数据结构的联系开放给⽤户态的⽅式, 它与 kobject ⼦系统紧密地结合在⼀起, 因此内核开发者不需要直接使⽤它, ⽽是内核的各个⼦系统使⽤它. ⽤户要想使⽤ sysfs 读取和设置内核参数, 仅需装载 sysfs 就可以通过⽂件操作应⽤来读取和设置内核通过 sysfs 开放给⽤户的各个参数:mkdir -p /sysfsmount -t sysfs sysfs /sysfs12注意, 不要把 sysfs 和 sysctl 混淆, sysctl 是内核的⼀些控制参数, 其⽬的是⽅便⽤户对内核的⾏为进⾏控制, ⽽ sysfs 仅仅是把内核的 kobject 对象的层次关系与属性开放给⽤户查看, 因此 sysfs 的绝⼤部分是只读的, 模块作为⼀个 kobject 也被出⼝到 sysfs, 模块参数则是作为模块属性出⼝的, 内核实现者为模块的使⽤提供了更灵活的⽅式, 允许⽤户设置模块参数在 sysfs 的可见性并允许⽤户在编写模块时设置这些参数在sysfs 下的访问权限, 然后⽤户就可以通过 sysfs 来查看和设置模块参数, 从⽽使得⽤户能在模块运⾏时控制模块⾏为.⽤户空间与内核空间数据交换的⽅式(6)——模块参数与sysfs2.3 debugfs⽂件系统内核开发者经常需要向⽤户空间应⽤输出⼀些调试信息, 在稳定的系统中可能根本不需要这些调试信息, 但是在开发过程中, 为了搞清楚内核的⾏为, 调试信息⾮常必要, printk可能是⽤的最多的, 但它并不是最好的, 调试信息只是在开发中⽤于调试, ⽽ printk 将⼀直输出, 因此开发完毕后需要清除不必要的 printk 语句, 另外如果开发者希望⽤户空间应⽤能够改变内核⾏为时, printk 就⽆法实现.因此, 需要⼀种新的机制, 那只有在需要的时候使⽤, 它在需要时通过在⼀个虚拟⽂件系统中创建⼀个或多个⽂件来向⽤户空间应⽤提供调试信息.有⼏种⽅式可以实现上述要求:使⽤ procfs, 在 /proc 创建⽂件输出调试信息, 但是 procfs 对于⼤于⼀个内存页(对于 x86 是 4K)的输出⽐较⿇烦, ⽽且速度慢, 有时回出现⼀些意想不到的问题.使⽤ sysfs( 2.6 内核引⼊的新的虚拟⽂件系统), 在很多情况下, 调试信息可以存放在那⾥, 但是sysfs主要⽤于系统管理,它希望每⼀个⽂件对应内核的⼀个变量,如果使⽤它输出复杂的数据结构或调试信息是⾮常困难的.使⽤ libfs 创建⼀个新的⽂件系统, 该⽅法极其灵活, 开发者可以为新⽂件系统设置⼀些规则, 使⽤ libfs 使得创建新⽂件系统更加简单, 但是仍然超出了⼀个开发者的想象.为了使得开发者更加容易使⽤这样的机制, Greg Kroah-Hartman 开发了 debugfs(在 2.6.11 中第⼀次引⼊), 它是⼀个虚拟⽂件系统, 专门⽤于输出调试信息, 该⽂件系统⾮常⼩, 很容易使⽤, 可以在配置内核时选择是否构件到内核中, 在不选择它的情况下, 使⽤它提供的API的内核部分不需要做任何改动.⽤户空间与内核空间数据交换的⽅式(1)——debugfsLinux内核⾥的DebugFSLinux驱动调试的Debugfs的使⽤简介Linux Debugfs⽂件系统介绍及使⽤Linux内核⾥的DebugFSDebugging the Linux Kernel with debugfsdebugfs-seq_fileLinux Debugfs⽂件系统介绍及使⽤Linux ⽂件系统:procfs, sysfs, debugfs ⽤法简介⽤户空间与内核空间数据交换的⽅式(1)——debugfsLinux 运⽤debugfs调试⽅法2.4 relayfs⽂件系统relayfs 是⼀个快速的转发(relay)数据的⽂件系统, 它以其功能⽽得名. 它为那些需要从内核空间转发⼤量数据到⽤户空间的⼯具和应⽤提供了快速有效的转发机制.Channel 是 relayfs ⽂件系统定义的⼀个主要概念, 每⼀个 channel 由⼀组内核缓存组成, 每⼀个 CPU 有⼀个对应于该 channel 的内核缓存,每⼀个内核缓存⽤⼀个在 relayfs ⽂件系统中的⽂件⽂件表⽰, 内核使⽤ relayfs 提供的写函数把需要转发给⽤户空间的数据快速地写⼊当前CPU 上的 channel 内核缓存, ⽤户空间应⽤通过标准的⽂件 I/ O函数在对应的 channel ⽂件中可以快速地取得这些被转发出的数据 mmap 来. 写⼊到 channel 中的数据的格式完全取决于内核中创建channel 的模块或⼦系统.relayfs 的⽤户空间API :relayfs 实现了四个标准的⽂件 I/O 函数, open、mmap、poll和close函数描述open 打开⼀个 channel 在某⼀个 CPU 上的缓存对应的⽂件.mmap 把打开的 channel 缓存映射到调⽤者进程的内存空间.read 读取 channel 缓存, 随后的读操作将看不到被该函数消耗的字节, 如果 channel 的操作模式为⾮覆盖写, 那么⽤户空间应⽤在有内核模块写时仍可以读取, 但是如 channel 的操作模式为覆盖式, 那么在读操作期间如果有内核模块进⾏写,结果将⽆法预知, 因此对于覆盖式写的channel, ⽤户应当在确认在 channel 的写完全结束后再进⾏读.poll ⽤于通知⽤户空间应⽤转发数据跨越了⼦缓存的边界, ⽀持的轮询标志有 POLLIN、POLLRDNORM 和 POLLERRclose 关闭 open 函数返回的⽂件描述符, 如果没有进程或内核模块打开该 channel 缓存, close 函数将释放该channel 缓存注意 : ⽤户态应⽤在使⽤上述 API 时必须保证已经挂载了 relayfs ⽂件系统, 但内核在创建和使⽤ channel时不需要relayfs 已经挂载. 下⾯命令将把 relayfs ⽂件系统挂载到 /mnt/relay.⽤户空间与内核空间数据交换的⽅式(4)——relayfsRelay:⼀种内核到⽤户空间的⾼效数据传输技术2.5 seq_file⼀般地, 内核通过在 procfs ⽂件系统下建⽴⽂件来向⽤户空间提供输出信息, ⽤户空间可以通过任何⽂本阅读应⽤查看该⽂件信息, 但是procfs 有⼀个缺陷, 如果输出内容⼤于1个内存页, 需要多次读, 因此处理起来很难, 另外, 如果输出太⼤, 速度⽐较慢, 有时会出现⼀些意想不到的情况, Alexander Viro 实现了⼀套新的功能, 使得内核输出⼤⽂件信息更容易, 该功能出现在 2.4.15(包括 2.4.15)以后的所有 2.4 内核以及2.6 内核中, 尤其是在 2.6 内核中,已经⼤量地使⽤了该功能⽤户空间与内核空间数据交换的⽅式(3)——seq_file内核proc⽂件系统与seq接⼝(4)—seq_file接⼝编程浅析Linux内核中的seq操作seq_file源码分析⽤序列⽂件(seq_file)接⼝导出常⽤数据结构seq_file机制3 printk在内核调试技术之中, 最简单的就是 printk 的使⽤了, 它的⽤法和C语⾔应⽤程序中的 printf 使⽤类似, 在应⽤程序中依靠的是 stdio.h 中的库,⽽在 linux 内核中没有这个库, 所以在 linux 内核中, 实现了⾃⼰的⼀套库函数, printk 就是标准的输出函数linux内核调试技术之printk调整内核printk的打印级别linux设备驱动学习笔记–内核调试⽅法之printk4 ftrace && trace-cmd4.1 trace && ftraceLinux当前版本中, 功能最强⼤的调试、跟踪⼿段. 其最基本的功能是提供了动态和静态探测点, ⽤于探测内核中指定位置上的相关信息.静态探测点, 是在内核代码中调⽤ ftrace 提供的相应接⼝实现, 称之为静态是因为, 是在内核代码中写死的, 静态编译到内核代码中的, 在内核编译后, 就不能再动态修改. 在开启 ftrace 相关的内核配置选项后, 内核中已经在⼀些关键的地⽅设置了静态探测点, 需要使⽤时, 即可查看到相应的信息.动态探测点, 基本原理为 : 利⽤ mcount 机制, 在内核编译时, 在每个函数⼊⼝保留数个字节, 然后在使⽤ ftrace时, 将保留的字节替换为需要的指令, ⽐如跳转到需要的执⾏探测操作的代码。
Linux内核Crash分析在工作中经常会遇到一些内核crash的情况,本文就是根据内核出现crash后的打印信息,对其进行了分析,使用的内核版本为:Linux2.6.32。
每一个进程的生命周期内,其生命周期的范围为几毫秒到几个月。
一般都是和内核有交互,例如用户空间程序使用系统调用进入内核空间。
这时使用的不再是用户空间的栈空间,使用对应的内核栈空间。
对每一个进程来说,Linux内核都会把两个不同的数据结构紧凑的存放在一个单独为进程分配的存储空间中:一个是内核态的进程堆栈,另一个是紧挨进程描述符的数据结构thread_info,叫线程描述符。
内核的堆栈大小一般为8KB,也就是8192个字节,占用两个页。
在Linux-2.6.32内核中thread_info.h文件中有对内核堆栈的定义:1.#define THREAD_SIZE 8192在Linux内核中使用下面的联合结构体表示一个进程的线程描述符和内核栈,在内核中文件include/linux/sched.h。
1.union thread_union {2.struct thread_info thread_info;3.unsigned long stack[THREAD_SIZE/sizeof(long)];4.};该结构是一个联合体,我们在C语言书上看到过关于union的解释,在在C Programming Language 一书中对于联合体是这么描述的:1) 联合体是一个结构;2) 它的所有成员相对于基地址的偏移量都为0;3) 此结构空间要大到足够容纳最"宽"的成员;4) 其对齐方式要适合其中所有的成员;通过上面的描述可知,thread_union结构体的大小为8192个字节。
也就是stack数组的大小,类型是unsigned long类型。
由于联合体中的成员变量都是占用同一块内存区域,所以,在平时写代码时总有一个概念,对一个联合体的实例只能使用其中一个成员变量,否则会把原先变量给覆盖掉,这句话如果正确的话,必须要有一个前提假设,成员占用的字节数相同,当成员所占的字节数不同时,只会覆盖相应的字节。
Kernel Debug using Crash utility
0. Crash introduction (3)
1. Filestore Specified (3)
2. Starting Point (4)
2.1 Check system basic info (4)
2.2 Check what’s latest kernel log, (5)
2.3 Check which processes are in ‘D’ state, what’s the number? (5)
2.4 Check memory status (6)
2.5 Check which process eat most memory (7)
2.6 Check which process each most of CPU (8)
2.7 Check IOWAIT for each process (only worked after 5.7) (9)
2.8 Check if “dirty page issue existed” (9)
2.9 Check the stack for “write” system call (9)
3. Common Utility (10)
4. Case Analysis (10)
4.1 Escalation 413-673-127 (10)
4.2 [PRI2][2316592] after slave node changed to primary, it reboot automatically itself . 11
5. Appendix (11)
5.1 Where to find related debug version VxFS and VxVM (11)
5.2 How to load debug info while running “crash” (11)
6. Reference (14)
0.Crash introduction
The Red Hat crash analysis utility is loosely based on the SVR4 UNIX crash command, but has been significantly enhanced by completely merging it with the GNU gdb debugger. The marriage of the two effectively combines the kernel-specific nature of the traditional UNIX crash utility with the source code level debugging capabilities of gdb.
Crash utility can be used to debug:
∙Live environment
∙Coredump triggered by some issues (such as “null pointer dereference” issue)
∙Coredump triggered by ‘sysrq-trigger’ manually (such as “system hung” issue)
1.Filestore Specified
In order to make sure crash can work well in Filestore,
∙We have to install some “kernel-kdump” related package. (It is installed in Filestore by default, Following example are from 5.6P2).
∙Make sure kernel object file existed
∙Know where is the coredump file
∙Know where is the Linux kernel source tree (in Filestore 5.6 and 5.7, kernel-source rpm package are installed by default)
∙Know the compile options for this kernel
2.Starting Point
2.3Check which processes are in ‘D’ state, what’s the number?(If
there are many process in ‘D’ statue, maybe there are some I/O
2.7Check IOWAIT for each process (only worked after 5.7)
mon Utility
∙grep (grep –A, grep –B,grep -C)
∙foreach
∙LXR server(http://10.200.100.240/lxr/http/source )
4.Case Analysis
4.1Escalation 413-673-127
Please check http://10.200.100.175/gf/download/docmanfileversion/58/1755/413-673-127_report.docx
4.2[PRI2][2316592] after slave node changed to primary, it reboot
automatically itself
Please check
http://10.200.100.175/gf/download/docmanfileversion/60/1763/2316592_report.docx
5.Appendix
5.1Where to find related debug version VxFS and VxVM
IOnce we know the VxFS /VxVM rpm version, we can find related branch and package (include debug package) easily from /engineering/file-system/scm/
For example, we got a VxFS issue in 5.5RP2HF2.
a)Check VXFS version
Cluster5_02:~ # rpm -qa|grep -i vxfs
VRTSvxfs-platform-5.0.30.332-MP3RP3HF32_SLES10
VRTSvxfs-common-5.0.30.332-MP3RP3HF32_SLES10
b)Check /engineering/file-
system/scm/linux_5_0_release_chart.html -> (search “5.0MP3RP3”) ->
/engineering/file-system/scm/5.0MP3RP3_linux.html ->
(search “HF32”) to jump to related section.
And we can found
∙Branch tag “s_Lx_5_0_MP3RP3HF32_2010-12-15”
∙RPM
location “ /build/delivery/VxFS_5.0MP3RP/5.0
MP3RP3HF32_linux/sles10_x86_64”
[notice: is a nfs server,]
How can we got debug version ko for vxfs? And how to load it
6.Reference
/anderson/crash_whitepaper/
http://10.200.100.175/gf/download/docmanfileversion/58/1755/413-673-127_report.docx
http://10.200.100.175/gf/download/docmanfileversion/60/1763/2316592_report.docx /engineering/file-system/scm/。