Linux中使用Systemtap调试SLUB

《Linux指令&＃xff1a;SystemTap内核跟踪和探测工具》

之前的文章曾利用systemtap的"watchpoint"功能来监测变量数值的变化&＃xff0c;但systemtap在内核debug中的应用远不止此&＃xff0c;本文将借由对SLUB的调试&＃xff0c;展现systemtap的其他一些功能。

相比起近两年才出现的bpftrace&＃xff0c;自2005年就作为RHEL 4.2中technology preview推出的systemtap算是历史悠久。伴随这么多年的发展&＃xff0c;systemtap积累了丰富且成熟的功能&＃xff0c;但同时它也是一个相对「重型」的工具。说它重型&＃xff0c;是因为它要求安装的软件包&＃xff0c;比crash工具还要多&＃xff1a;

# rpm -qa | egrep -e kernel-&＃39;(devel|debug)&＃39; -e systemtap
kernel-debuginfo-common-x86_64-3.10.0-1062.el7.x86_64
kernel-debuginfo-3.10.0-1062.el7.x86_64
kernel-devel-3.10.0-1062.el7.x86_64
systemtap-client-4.0-11.el7.x86_64
systemtap-devel-4.0-11.el7.x86_64
systemtap-runtime-4.0-11.el7.x86_64

除了crash工具依赖的debuginfo&＃xff0c;systemtap还需要额外的一些组件&＃xff0c;而它的使用之所以需要这些包&＃xff0c;其实可以从它的workflow看出来&＃xff1a;

把这堆东西安装完后&＃xff0c;可通过以下命令验证功能是否真正可用&＃xff1a;

stap -v -e &＃39;probe vfs.read { printf("read performed\n"); exit() }&＃39;

所安装的"kernel-devel"不仅需与当前内核版本保持一致&＃xff0c;其编译时间也需匹配&＃xff08;对&＃xff0c;就是这么矫情&＃xff09;&＃xff0c;否则会出现错误 "ERROR: module version mismatch"&＃xff0c;可对照"/proc/version"修改"/usr/src/kernels/$(uname -r)/include/generated/compile.h"文件来解决。

systemtap有着一套自己的语法体系&＃xff0c;不过与C语言的风格差别不大&＃xff0c;配合其众多的examples&＃xff08;安装后位于"/usr/share/systemtap/"目录&＃xff09;&＃xff0c;入门并不困难。事实上&＃xff0c;systemtap脚本&＃xff08;以下称"stap"&＃xff09;在结合debuginfo的信息解析了symbol后&＃xff0c;也是转化为C语言&＃xff0c;进而编译成一个kernel module来运行的。

又是解析&＃xff0c;又是编译&＃xff0c;整个过程在第一次的时候耗时还是比较长的&＃xff0c;所以笔者一般都会加上代表verbose的"-v"参数来观察这中间的过程。好在它会将编译的结果以cache的形式保存起来&＃xff0c;下次再执行同样的stap脚本&＃xff0c;就比较迅速了。

其实它能做的事&＃xff0c;你自己写一个kernel module&＃xff0c;理论上也能做&＃xff0c;但写脚本&＃xff0c;还是方便多了。如果用传统的printk打印的话&＃xff0c;可能还需要重新编译内核&＃xff0c;就更麻烦了。

不仅是syscall&＃xff08;在stap中关键字为"syscall"&＃xff0c;对比strace&＃xff09;&＃xff0c;也不仅是函数的入口和出口&＃xff08;在stap中关键字为"function"&＃xff0c;对比ftrace&＃xff09;&＃xff0c;这家伙能追踪的点&＃xff0c;基本是任一address&＃xff08;在stap中关键字为"statement"&＃xff09;&＃xff0c;甚至以源代码行数的形式喂给它都认得&＃xff08;毕竟有debuginfo不是&＃xff09;&＃xff0c;比如&＃xff1a;

probe kernel.statement("tcp_sendmsg&＃64;net/ipv4/tcp.c:1320")

有时我们想追一个驱动模块的启动阶段&＃xff08;模块的probe格式为"module(xxx)"&＃xff09;&＃xff0c;那么在这个模块加载前&＃xff0c;就通过systemtap埋伏好点位&＃xff0c;也是完全可以达到目的的&＃xff08;现在有没有觉得前面安装那么多东西还是值得的&＃xff09;。

这种强悍的能力&＃xff0c;源于它基于的底层机制&＃xff0c;即kprobe&＃xff08;不过stap脚本使用的关键字是"probe"&＃xff0c;反倒是后面文章要介绍的bpftrace用的关键字"kprobe"&＃xff0c;不要搞混了&＃xff09;。

kprobe的实现机理在不同的arch上有一定的差异&＃xff0c;就x86而言&＃xff0c;它采用的是将被追踪指令先保存起来&＃xff0c;然后将其第一个字节替换成breakpoint指令&＃xff08;比如"int3"&＃xff09;。当CPU执行到这条指令&＃xff0c;触发trap&＃xff0c;相关寄存器被保存&＃xff0c;控制权被kprobe劫持&＃xff0c;然后&＃xff0c;就可以为所欲为了。

干完自己想干的事&＃xff0c;kprobe会单步执行之前保存的原始指令&＃xff0c;接下来它可以直接归还控制权&＃xff0c;或者再执行个"post-handler"&＃xff08;在原始指令执行前的动作则对应为"pre-handler"&＃xff09;。

用户态进程可以通过gdb被真正地暂停&＃xff0c;使用RTOS或者bare-metal的嵌入式系统也可以通过硬件断点或者软件断点的方式停下来&＃xff0c;但Linux内核不行&＃xff0c;因此&＃xff0c;借助systemtap来在线获取变量信息、打印backtrace、修改返回值等&＃xff0c;就成为了尤为重要的调试手段。

说起「修改返回值」&＃xff0c;systemtap还有一个妙用。在coredump领域几乎是事实标准的crash工具&＃xff0c;也可以用于在线分析&＃xff0c;包括动态地修改指定内存的值&＃xff0c;但是在crash工具中直接使用"wr"命令往往是不行的&＃xff0c;因为"/dev/mem"的使用被限制了。而我们的systemtap&＃xff0c;则可以通过修改"devmem_is_allowed"函数的返回值&＃xff0c;来帮助crash工具绕过这一限制。

stap -g -e &＃39;probe kernel.function("devmem_is_allowed").return { $return &＃61; 1 }&＃39;

说了那么多&＃xff0c;还是回到用systemtap收集SLUB的信息上来&＃xff08;要不然本文真的有跑题的嫌疑……&＃xff09;。

要分析SLUB的内存分配&＃xff0c;最好是track调用链比较内层的"slab_alloc_node"函数&＃xff0c;以获得更全面的覆盖。可惜这个函数被inline了&＃xff0c;无法识别入参&＃xff0c;因此本文退而求其次&＃xff0c;改为追踪"kmem_cache_alloc"函数。脚本大致如下&＃xff1a;

#!/usr/bin/stapglobal slab_alloc_stackprobe kernel.function("kmem_cache_alloc"){
slab_alloc_stack[backtrace()]&＃43;&＃43;
}probe timer.s(5){
foreach (bt in slab_alloc_stack) {
println("")
print_syms(bt)
printf("alloc %d times\n", slab_alloc_stack[bt])}}

"slab_alloc_stack"是一个associative array&＃xff08;关联数组&＃xff0c;即不仅可以通过整数来索引&＃xff0c;还可以使用字符串或其他类型的值来索引的数组&＃xff09;。在这个示例中, "backtrace()"就是索引&＃xff08;key&＃xff09;&＃xff0c;某一种backtrace出现的次数就是"value"。

考虑到「关联数组」通常体积较大&＃xff0c;不适合动态分配&＃xff0c;且往往被多个函数共享&＃xff0c;因此其在systemtap中只能被定义为「全局变量」的形式&＃xff08;关键字为"global"&＃xff09;。

由于stap脚本通常用来追踪一个函数&＃xff0c;因此说到变量&＃xff0c;需要注意区分是stap脚本自己定义的变量&＃xff0c;还是所追踪的函数的变量&＃xff08;target varible&＃xff09;。不知道你注意到没有&＃xff0c;stap脚本自己用的变量并没有申明类型&＃xff0c;这是因为其类型是在赋值时被自动判定的。

"kernel.function"前面已经介绍过了&＃xff0c;它属于同步触发的probe点。而"timer"属于异步触发的probe点&＃xff0c;表示每隔多长时间执行一次&＃xff08;这里是5秒&＃xff09;&＃xff0c;"foreach"用于对关联数组的遍历。

使用"stap -v slub-top.stp"执行该脚本&＃xff1a;

打印的stack里面有的地方只能显示address&＃xff0c;不能显示symbol&＃xff0c;同时在stap脚本的执行过程中&＃xff0c;会出现很多这样的打印&＃xff1a;

WARNING: Missing unwind data for a module, rerun with &＃39;stap -d xxx&＃39;

缺失的这些symbol属于内核模块&＃xff0c;默认没有被加载&＃xff0c;如果确切地知道是缺少哪个内核模块的debug信息&＃xff0c;可以通过"-d"指定&＃xff0c;如果缺失的比较多&＃xff08;比如本文这种情况&＃xff09;&＃xff0c;那就直接用"--all-modules"吧。

现在symbol的问题算是解决了&＃xff0c;但输出的内容里&＃xff0c;既没有申请分配SLUB的进程名称&＃xff0c;也没有SLUB对象的类型和大小&＃xff0c;并没有太多的分析价值。而要想获得这些额外的信息&＃xff0c;可以从被probe的函数的参数入手。

# stap -L &＃39;kernel.function("kmem_cache_alloc")&＃39; kernel.function("kmem_cache_alloc&＃64;mm/slub.c:2719") $s:struct kmem_cache* $gfpflags:gfp_t

dereference入参指针"s"&＃xff0c;便能拿到对应SLUB的名称和大小。"s"就是前面提到的target varible&＃xff0c;使用时需加上"$"符号。在stap的语法里&＃xff0c;不管是结构体还是结构体指针&＃xff0c;统一使用"->"来获取成员变量&＃xff08;"."在stap里是用来连接字符串的&＃xff09;。至于进程名么&＃xff0c;可直接用stap提供的"execname()"内置函数。

probe kernel.function("kmem_cache_alloc")
{
printf("alloc "%s" with size "%d", for process %s\n", $s->name, $s->size, execname())}

执行一下&＃xff0c;出现了错误&＃xff1a;

semantic error: type mismatch: expected string but found long: $s->name

因为"s->name"是"const char *"类型&＃xff0c;会被识别为指针&＃xff0c;所以这里应该用"kernel_string($s->name)"转换一下。

现在&＃xff0c;该有的信息倒是都齐备了&＃xff0c;但是未经统计和归纳&＃xff0c;难以直观地判断在一段时间内&＃xff0c;到底哪些进程才是消耗SLUB的狂魔&＃xff0c;又到底哪些SLUB在被这些狂魔贪婪地占有。下面&＃xff0c;将上述的2个示例组合一下&＃xff0c;来一点stap的进阶用法&＃xff1a;

probe kernel.function("kmem_cache_alloc")
{
slab_alloc_stack[execname(),kernel_string($s->name),backtrace()] <<<$s->size
}probe timer.s($1){
foreach ([proc,slub,bt] in slab_alloc_stack- limit $2) {
printf("Proc:%s Slub:%s Count:%d Sum:%d\n", proc, slub,
&＃64;count(slab_alloc_stack[proc,slub,bt], &＃64;sum(slab_alloc_stack[proc,slub,bt]))
print_syms(bt)
}exit()}

这个组合后的脚本的主要目的&＃xff0c;是根据关联数组的value来进行排序。在foreach循环里&＃xff0c;数组名后面跟的"-"代表递减排序&＃xff0c;"limit"表示取最为靠前的几个。

同时&＃xff0c;为了实现更灵活地控制&＃xff08;以及展现stap的更多用法&＃xff09;&＃xff0c;笔者分别使用了"$1"和"$2"来设定时长和limit数目&＃xff0c;而它们对应的都是脚本执行时传入的整型类参数&＃xff08;如果是字符串类参数则应该用"&＃64;1", "&＃64;2"&＃xff09;&＃xff1a;。

stap -v --all-modules slub-top-sort.stp 10 5

这里&＃xff0c;作为关联数组的"slab_alloc_stack"有进程名、SLUB名称和backtrace三个key&＃xff0c;其效果类似于一个三维数组。系统中有多个进程&＃xff0c;每个进程在进入内核态后可能申请的SLUB也有多种&＃xff0c;即便是同一个进程申请的同一种SLUB&＃xff0c;其调用栈的路径也可能不同。

对于这样一个key的组合&＃xff0c;假设对应SLUB的大小为256&＃xff0c;且在10秒的执行时间内被命中了4次&＃xff0c;使用"<<<"符号&＃xff0c;可以将这4次的数据都保存下来&＃xff0c;便于之后的统计处理。"&＃64;sum"用于聚合数据的累加值&＃xff08;即1024&＃xff09;&＃xff0c;一个可能有点容易混淆的概念是"&＃64;count"&＃xff0c;它汇总的是次数之和&＃xff08;即4&＃xff09;。

 在脚本中进一步结合"if"条件过滤&＃xff0c;可以单独看一个进程申请最多的前几种SLUB&＃xff0c;如果依然以SLUB的大小作为统计数值&＃xff0c;那么每次probe命中时的数值大小都可能不同&＃xff0c;这时计算最小值、平均值和最大值的"&＃64;min", "&＃64;avg"和"&＃64;max"就派上了用场。

原作者&＃xff1a;兰新宇