crash分析

内核栈溢出

在Linux系统上，进程运行分为用户态与内核态，进入内核态之后使用的是内核栈，作为基本的安全机制，用户程序不能直接访问内核栈，所以尽管内核栈属于进程的地址空间，但与用户栈是分开的。Linux的内核栈大小是固定的，从2.6.32-520开始缺省大小是16KB，之前的kernel版本缺省大小是8KB。内核栈的大小可以修改，但要通过重新编译内核实现。以下文件定义了它的大小：

arch/x86/include/asm/page_64_types.h
8KB:
#define THREAD_ORDER 1
16KB:
#define THREAD_ORDER 2

由于内核栈的大小是有限的，就会有发生溢出的可能，比如调用嵌套太多、参数太多都会导致内核栈的使用超出设定的大小。内核栈溢出的结果往往是系统崩溃，因为溢出会覆盖掉本不该触碰的数据，首当其冲的就是thread_info — 它就在内核栈的底部，内核栈是从高地址往低地址生长的，一旦溢出首先就破坏了thread_info，thread_info里存放着指向进程的指针等关键数据，迟早会被访问到，那时系统崩溃就是必然的事。kstack-smash

【小知识】：把thread_info放在内核栈的底部是一个精巧的设计，在高端CPU中比如PowerPC、Itanium往往都保留了一个专门的寄存器来存放当前进程的指针，因为这个指针的使用率极高，然而x86的寄存器太少了，专门分配一个寄存器实在太奢侈，所以Linux巧妙地利用了栈寄存器，把thread_info放在内核栈的底部，这样通过栈寄存器里的指针可以很方便地算出thread_info的地址，而thread_info的第一个字段就是进程的指针。

内核栈溢出导致的系统崩溃有时会被直接报出来，比如你可能会看到：

但更多的情况是不直接报错，而是各种奇怪的panic。在分析vmcore的时候，它们的共同点是thread_info被破坏了。以下是一个实例，注意在task_struct中stack字段直接指向内核栈底部也就是thread_info的位置，我们看到thread_info显然被破坏了：cpu的值大得离谱，而且指向task的指针与task_struct的实际地址不匹配：

作为一种分析故障的手段，可以监控内核栈的大小和深度，方法如下：

然后检查下列数值，可以看到迄今为止内核栈使用的峰值和对应的backtrace：

你可以写个脚本定时收集上述数据，有助于找到导致溢出的代码。下面是一个输出结果的实例：

 

crash分析、读核笔记

内核如何检测soft lockup与hard lockup？

所谓lockup，是指某段内核代码占着CPU不放。Lockup严重的情况下会导致整个系统失去响应。Lockup有几个特点：

  • 首先只有内核代码才能引起lockup，因为用户代码是可以被抢占的，不可能形成lockup（只有一种情况例外，就是SCHED_FIFO优先级为99的实时进程即使在用户态也可能使[watchdog/x]内核线程抢不到CPU而形成soft lock，参见《Real-Time进程会导致系统Lockup吗？》）
  • 其次内核代码必须处于禁止内核抢占的状态(preemption disabled)，因为Linux是可抢占式的内核，只在某些特定的代码区才禁止抢占，在这些代码区才有可能形成lockup。

Lockup分为两种：soft lockup 和 hard lockup，它们的区别是 hard lockup 发生在CPU屏蔽中断的情况下。

  • Soft lockup是指CPU被内核代码占据，以至于无法执行其它进程。检测soft lockup的原理是给每个CPU分配一个定时执行的内核线程[watchdog/x]，如果该线程在设定的期限内没有得到执行的话就意味着发生了soft lockup，[watchdog/x]是SCHED_FIFO实时进程，优先级为最高的99，拥有优先运行的特权。
  • Hard lockup比soft lockup更加严重，CPU不仅无法执行其它进程，而且不再响应中断。检测hard lockup的原理利用了PMU的NMI perf event，因为NMI中断是不可屏蔽的，在CPU不再响应中断的情况下仍然可以得到执行，它再去检查时钟中断的计数器hrtimer_interrupts是否在保持递增，如果停滞就意味着时钟中断未得到响应，也就是发生了hard lockup。

Linux kernel设计了一个检测lockup的机制，称为NMI Watchdog，是利用NMI中断实现的，用NMI是因为lockup有可能发生在中断被屏蔽的状态下，这时唯一能把CPU抢下来的方法就是通过NMI，因为NMI中断是不可屏蔽的。NMI Watchdog 中包含 soft lockup detector 和 hard lockup detector，2.6之后的内核的实现方法如下。

NMI Watchdog 的触发机制包括两部分：

  1. 一个高精度计时器(hrtimer)，对应的中断处理例程是kernel/watchdog.c: watchdog_timer_fn()，在该例程中：
    • 要递增计数器hrtimer_interrupts，这个计数器供hard lockup detector用于判断CPU是否响应中断；
    • 还要唤醒[watchdog/x]内核线程，该线程的任务是更新一个时间戳；
    • soft lock detector检查时间戳，如果超过soft lockup threshold一直未更新，说明[watchdog/x]未得到运行机会，意味着CPU被霸占，也就是发生了soft lockup。
  2. 基于PMU的NMI perf event，当PMU的计数器溢出时会触发NMI中断，对应的中断处理例程是 kernel/watchdog.c: watchdog_overflow_callback()，hard lockup detector就在其中，它会检查上述hrtimer的中断次数(hrtimer_interrupts)是否在保持递增，如果停滞则表明hrtimer中断未得到响应，也就是发生了hard lockup。

hrtimer的周期是：softlockup_thresh/5。
注：

  • 在2.6内核中：
    softlockup_thresh的值等于内核参数kernel.watchdog_thresh，默认60秒；
  • 而到3.10内核中：
    内核参数kernel.watchdog_thresh名称未变，但含义变成了hard lockup threshold，默认10秒；
    soft lockup threshold则等于（2*kernel.watchdog_thresh），即默认20秒。

NMI perf event是基于PMU的，触发周期（hard lockup threshold）在2.6内核里是固定的60秒，不可手工调整；在3.10内核里可以手工调整，因为直接对应着内核参数kernel.watchdog_thresh，默认值10秒。

检测到 lockup 之后怎么办？可以自动panic，也可输出条信息就算完了，这是可以通过内核参数来定义的：

  • kernel.softlockup_panic: 决定了检测到soft lockup时是否自动panic，缺省值是0；
  • kernel.nmi_watchdog: 定义是否开启nmi watchdog、以及hard lockup是否导致panic，该内核参数的格式是”=[panic,][nopanic,][num]”.
    （注：最新的kernel引入了新的内核参数kernel.hardlockup_panic，可以通过检查是否存在 /proc/sys/kernel/hardlockup_panic来判断你的内核是否支持。）

参考资料：

Softlockup detector and hardlockup detector (aka nmi_watchdog)

kernel/watchdog.c:
设置PMU NMI perf event的代码 wachdog_nmi_enable()
响应NMI perf overflow中断的代码 watchdog_overflow_callback()
[watchdog/x]内核线程 watchdog()
响应hrtimer中断的代码 watchdog_timer_fn()

读核笔记、进程管理

Real-Time进程会导致系统lockup吗？

Linux kernel支持两种实时(real-time)调度策略(scheduling policy)：SCHED_FIFO和SCHED_RR，无论是哪一种，实时进程的优先级范围[0~99]都高于普通进程[100~139]，始终优先于普通进程得到运行。如果实时进程是CPU消耗型的，会不会导致其它进程得不到运行机会，造成系统lockup呢？

这实际上是两个问题，不能混为一谈，第一个问题是会不会造成系统lockup，第二个问题是会不会导致其它进程得不到运行机会。我们一个一个分别来谈。

实时进程会不会造成系统lockup？

Lockup分为soft lockup和hard lockup，我在《内核如何检测SOFT LOCKUP与HARD LOCKUP》一文中解释了Linux kernel检测lockup的原理。

Hard lockup发生在CPU中断被屏蔽的情况下，因为实时进程本身并不会屏蔽CPU中断，hrtimer时钟中断是可以得到响应的，所以不会导致hard lockup。

Soft lockup发生在内核线程[watchdog/x]得不到运行的情况下，理论上如果实时进程占着CPU不放，确实有可能导致[watchdog/x]得不到运行而发生soft lockup，然而这个可能性并不大，因为[watchdog/x]本身也是实时进程，调度策略为SCHED_FIFO，优先级已经是最高的99：

如果占着CPU不放的实时进程也是SCHED_FIFO并且优先级为99，就有可能导致soft lockup。为什么呢？我们看一下实时进程的调度策略就明白了：

  • 在多个实时进程之间，优先级更高的会抢先运行
    （注：实时进程的优先级数字越大则优先级越高，99最高，0最低；而普通进程正好相反，优先级数字越大则优先级越低，139最低，100最高）；
  • 优先级相同的实时进程之间，不会互相抢占，只能等对方主动释放CPU；
  • SCHED_FIFO调度策略的特点是，进程会一直保持运行直到发生以下情况之一：
    1. 进程主动调用sched_yield(2)放弃运行，自动排到运行队列的队尾，等到相同优先级的其它进程运行之后才有机会再运行；
    2. 进程进入睡眠状态（比如由于等待I/O的原因），唤醒后自动排到运行队列的队尾，等到相同优先级的其它进程运行之后才有机会再运行；
    3. 被优先级更高的实时进程抢占，这种情况下会自动排到运行队列的队首，下次运行的机会排在相同优先级的其它进程的前面。
  • SCHED_RR进程与SCHED_FIFO唯一不同的是，实时进程的运行时间是分为一段一段的，在相同优先级的进程之间轮流运行，每个进程运行完一个时间段之后，必须让给下一个进程（强调：仅对相同优先级而言，不同优先级的进程之间仍然会互相抢占）。

所以，如果占着CPU不放的实时进程的调度策略是SCHED_FIFO，并且优先级为与[watchdog/x]相同的99，SCHED_FIFO的调度策略决定了只要它不放手，[watchdog/x]就无法运行，结果是会导致soft lockup。

接下来第二个问题是：

实时进程会不会导致其它进程得不到运行机会？

如果实时进程占着CPU不放，会不会导致其它进程得不到运行机会，包括管理员的shell也无法运行、连基本的管理任务也进行不了，最终造成整个系统失去控制？

通常不会。因为Linux kernel有一个RealTime Throttling机制，就是为了防止CPU消耗型的实时进程霸占所有的CPU资源而造成整个系统失去控制。它的原理很简单，就是保证无论如何普通进程都能得到一定比例（默认5%）的CPU时间，可以通过两个内核参数来控制：

  • /proc/sys/kernel/sched_rt_period_us
    缺省值是1,000,000 μs (1秒)，表示实时进程的运行粒度为1秒。（注：修改这个参数请谨慎，太大或太小都可能带来问题）。
  • /proc/sys/kernel/sched_rt_runtime_us
    缺省值是 950,000 μs (0.95秒)，表示在1秒的运行周期里所有的实时进程一起最多可以占用0.95秒的CPU时间。
    如果sched_rt_runtime_us=-1，表示取消限制，意味着实时进程可以占用100%的CPU时间（慎用，有可能使系统失去控制）。

所以，Linux kernel默认情况下保证了普通进程无论如何都可以得到5%的CPU时间，尽管系统可能会慢如蜗牛，但管理员仍然可以利用这5%的时间设法恢复系统，比如停掉失控的实时进程，或者给自己的shell进程赋予更高的实时优先级以便执行管理任务，等等。

Real-time Throttling支持cgroup，详见https://www.kernel.org/doc/Documentation/scheduler/sched-rt-group.txt

参考资料：
https://lwn.net/Articles/296419/

内存

free命令显示的buffers与cached的区别

free 命令是Linux系统上查看内存使用状况最常用的工具，然而很少有人能说清楚 “buffers” 与 “cached” 之间的区别：

我们先抛出结论，如果你对研究过程感兴趣可以继续阅读后面的段落：

“buffers” 表示块设备(block device)所占用的缓存页，包括：直接读写块设备、以及文件系统元数据(metadata)比如SuperBlock所使用的缓存页；
“cached” 表示普通文件数据所占用的缓存页。

下面是分析过程：

先用 strace 跟踪 free 命令，看看它是如何计算 “buffers” 和 “cached” 的：

显然 free 命令是从 /proc/meminfo 中读取信息的，跟我们直接读到的结果一样：

那么 /proc/meminfo 中的 “Buffers” 和 “Cached” 又是如何得来的呢？这回没法偷懒，只能去看源代码了。源代码文件是：fs/proc/meminfo.c ，我们感兴趣的函数是：meminfo_proc_show()，阅读得知：

“Cached” 来自于以下公式：
global_page_state(NR_FILE_PAGES) – total_swapcache_pages – i.bufferram

global_page_state(NR_FILE_PAGES) 表示所有的缓存页(page cache)的总和，它包括：

  • “Cached”
  • “Buffers” 也就是上面公式中的 i.bufferram，来自于 nr_blockdev_pages() 函数的返回值。
  • 交换区缓存(swap cache)

global_page_state(NR_FILE_PAGES) 来自 vmstat[NR_FILE_PAGES]，vmstat[NR_FILE_PAGES] 可以通过 /proc/vmstat 来查看，表示所有缓存页的总数量：

注意以上nr_file_pages是以page为单位（一个page等于4KB），而free命令是以KB为单位的。

直接修改 nr_file_pages 的内核函数是：
__inc_zone_page_state(page, NR_FILE_PAGES) 和
__dec_zone_page_state(page, NR_FILE_PAGES)，
一个用于增加，一个用于减少。

Swap Cache是什么？

用户进程的内存页分为两种：file-backed pages（与文件对应的内存页）和anonymous pages（匿名页）。匿名页(anonymous pages)是没有关联任何文件的，比如用户进程通过malloc()申请的内存页，如果发生swapping换页，它们没有关联的文件进行回写，所以只能写入到交换区里。

交换区可以包括一个或多个交换区设备（裸盘、逻辑卷、文件都可以充当交换区设备），每一个交换区设备在内存里都有对应的swap cache，可以把swap cache理解为交换区设备的”page cache”：page cache对应的是一个个文件，swap cache对应的是一个个交换区设备，kernel管理swap cache与管理page cache一样，用的都是radix-tree，唯一的区别是：page cache与文件的对应关系在打开文件时就确定了，而一个匿名页只有在即将被swap-out的时候才决定它会被放到哪一个交换区设备，即匿名页与swap cache的对应关系在即将被swap-out时才确立。

并不是每一个匿名页都在swap cache中，只有以下情形之一的匿名页才在：

  • 匿名页即将被swap-out时会先被放进swap cache，但通常只存在很短暂的时间，因为紧接着在pageout完成之后它就会从swap cache中删除，毕竟swap-out的目的就是为了腾出空闲内存；
    【注：参见mm/vmscan.c: shrink_page_list()，它调用的add_to_swap()会把swap cache页面标记成dirty，然后它调用try_to_unmap()将页面对应的page table mapping都删除，再调用pageout()回写dirty page，最后try_to_free_swap()会把该页从swap cache中删除。】
  • 曾经被swap-out现在又被swap-in的匿名页会在swap cache中，直到页面中的内容发生变化、或者原来用过的交换区空间被回收为止。
    【注：当匿名页的内容发生变化时会删除对应的swap cache，代码参见mm/swapfile.c: reuse_swap_page()。】
“cached”：

“Cached” 表示除去 “buffers” 和 “swap cache” 之外，剩下的也就是普通文件的缓存页的数量：
global_page_state(NR_FILE_PAGES) – total_swapcache_pages – i.bufferram
所以关键还是要理解 “buffers” 是什么含义。

“buffers” ：

从源代码中看到，”buffers” 来自于 nr_blockdev_pages() 函数的返回值：

这段代码的意思是遍历所有的块设备(block device)，累加每个块设备的inode的i_mapping的页数，统计得到的就是 buffers。显然 buffers 是与块设备直接相关的。

那么谁会更新块设备的缓存页数量(nrpages)呢？我们继续向下看。

搜索kernel源代码发现，最终更新mapping->nrpages字段的函数就是：
pagemap.h: add_to_page_cache
> filemap.c: add_to_page_cache_locked
>  __add_to_page_cache_locked
> page_cache_tree_insert
和：
filemap.c: delete_from_page_cache
> __delete_from_page_cache
> page_cache_tree_delete

这两个函数是通用的，block device 和 文件inode 都可以调用，至于更新的是块设备的(buffers)还是文件的(cached)，取决于参数变量mapping：如果mapping对应的是块设备，那么相应的统计信息会反映在 “buffers” 中；如果mapping对应的是文件inode，影响的就是 “cached”。我们下面看看kernel中哪些地方会把块设备的mapping传递进来。

首先是块设备本身，打开时使用 bdev->bd_inode->i_mapping。

其次，文件系统的Superblock也是使用块设备：

sb表示SuperBlock，s_bdev就是块设备。Superblock是文件系统的metadata（元数据），不属于文件，没有对应的inode，所以，对metadata操作所涉及的缓存页都只能利用块设备mapping，算入 buffers 的统计值内。

如果文件含有间接块(indirect blocks)，因为间接块也属于metadata，所以走的也是块设备的mapping。查看源代码，果然如此：

这样我们就知道了”buffers” 是块设备(block device)占用的缓存页，分为两种情况：

  • 直接对块设备进行读写操作；
  • 文件系统的metadata（元数据），比如 SuperBlock。
验证：

现在我们来做个测试，验证一下上述结论。既然文件系统的metadata会用到 “buffers”，我们用 find 命令扫描文件系统，观察 “buffers” 增加的情况：

再测试一下直接读取block device，观察”buffers”增加的现象：

 结论：

free 命令所显示的 “buffers” 表示块设备(block device)所占用的缓存页，包括直接读写块设备、以及文件系统元数据(metadata)如SuperBlock所使用的缓存页；
而 “cached” 表示普通文件所占用的缓存页。

内存

用kmemleak检测内核内存泄漏

所谓内存泄漏(memory leak)，是指分配出去的内存在用完之后忘了释放，造成内存浪费，可用的内存越来越少。内存泄漏是程序设计的错误导致的，既可能发生在用户程序里，也可能发生在内核中。

诊断内存泄漏问题的目标是定位为什么内存用完之后会忘了释放，最终都是需要阅读源代码，理解内在的逻辑，找出其中的错误。作为最基本的分析线索，我们至少需要观察内存的分配与释放操作，还有一些更高级的工具可以帮助我们找出无人引用的内存块以及最初分配它的backtrace，这就更有针对性了。诊断用户态程序内存泄漏最流行的工具是Valgrind，对于内核，类似的工具是kmemleak。

kmemleak的原理

kmemleak通过追踪kmalloc(), vmalloc(), kmem_cache_alloc()等函数，把分配内存的指针和大小、时间、stack trace等信息记录在一个rbtree中，等到调用free释放内存时就把相应的记录从rbtree中删除，也就是说rbtree中的记录就是已经分配出去但尚未释放的内存，其中有些内存尚未释放是因为还在被使用，这属于正常情况，而不正常的情况即内存尚未释放但又不会再被使用，就是“泄漏”的内存，那么如何找出泄漏的内存呢？kmemleak缺省每10分钟对内存做一次扫描，在内存中寻找rbtree中记录的地址，如果某个rbtree记录的地址在内存中找不到，就认为这个地址是无人引用的，以后也不可能再被用到，是“泄漏”的内存，然后，把这些泄漏的内存地址以及rbtree中记录的时间、大小、strack trace等相关信息通过 /sys/kernel/debug/kmemleak 这个接口展现给我们。

注：
kmemleak的扫描算法存在误报的可能，比如内存中碰巧有一个数据与rbtree中的某个地址相同，但它只是数据而非指针，kmemleak是无法分辨的，会把它当作访问内存的指针；再比如rbtree中的某个地址在内存中找不到，但程序可能还在用它，只是因为程序并没有直接保存访问地址，而是通过某种方式临时计算访问地址，这种情况kmemleak也无法分辨，会认为是泄漏。但是请注意，kmemleak 这个工具的目的是为了给进一步分析提供线索，并不需要绝对精确，小概率的误报并不影响这个工具的实用性。

怎样启用kmemleak

要启用kmemleak，前提是内核编译时在“Kernel hacking”中开启了 CONFIG_DEBUG_KMEMLEAK 选项。怎样知道一个运行系统的内核是否支持kmemleak呢？可以查看 /boot/config-$(uname -r) 配置文件中 CONFIG_DEBUG_KMEMLEAK 是否等于”y”。以RHEL6为例，它的debug kernel是支持kmemleak的，我们看它的config文件：

  • CONFIG_DEBUG_KMEMLEAK=y
    表示内核支持kmemleak；
  • CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y
    表示kmemleak默认是关闭的，需要显式启用，启用的方式是在kernel command line中添加以下选项：
    kmemleak=on
怎样使用kmemleak

kmemleak的用户接口是：
/sys/kernel/debug/kmemleak
发送指令和输出信息都是通过以上文件进行的。要访问这个文件，必须先挂载以下文件系统：
# mount -t debugfs nodev /sys/kernel/debug/

kmemleak缺省每10分钟扫描内存一次，找到可疑的内存泄漏会在syslog中写一条记录并提示通过/sys/kernel/debug/kmemleak可以看到更详细的信息：

也可以手工发起kmemleak的内存扫描：
# echo scan > /sys/kernel/debug/kmemleak

还可以调整kmemleak内存扫描的频率等参数，更多的操作详见手册：
https://www.kernel.org/doc/html/latest/dev-tools/kmemleak.html

参考资料：
http://tekkamanninja.blog.chinaunix.net/uid-26859697-id-5758036.html

 

内存

如何诊断SLUB问题

在前文中，我们介绍了在RHEL6及较早的kernel上诊断slab泄漏问题的两种方法，可以说相当麻烦了，这是因为以前的slab没有提供原生的故障诊断机制。Linux kernel自2.6.23之后采用的Slub自带了故障诊断机制，就方便很多，然而习惯上仍然把slub称作slab。如何判断你的系统kernel是否在用slub呢？仅从kernel版本号是看不准的，比如RHEL6的kernel版本2.6.x仍然在使用slab，从RHEL7才开始采用Slub。有一个简单的判断方法，就是看是否存在/sys/kernel/slab目录，有就是slub，没有就是slab。

Slub的debug机制

了解slub的debug机制之前，先要弄清楚可能会出现哪些问题，无论是slab还是slub，问题无非是以下几类：

  • 内存泄露（leak），alloc之后忘了free，导致内存占用不断增长；
  • 越界（overrun），访问了alloc分配的区域之外的内存，覆盖了不属于自己的数据；
  • 使用已经释放的内存（use after free），正常情况下，已经被free释放的内存是不应该再被读写的，否则就意味着程序有bug；
  • 使用未经初始化的数据（use uninitialised bytes），缺省模式下alloc分配的内存是不被初始化的，内存值是随机的，直接使用的话后果可能是灾难性的。

Slub提供了red zone和poisoning等debug机制来检测以上问题。

  • Red zone来自于橄榄球术语，是指球场底线附近的区域，slub通过在每一个对象后面额外添加一块red zone区域来帮助检测越界(overrun)问题，在red zone里填充了特征字符，如果代码访问到了red zone就意味着越界了。
  • Poisoning是通过往slub对象中填充特征字符的方式来检测use-after-free、use-uninitialised等问题，比如在分配slub对象时填充0x5a，在释放时填充0x6b，然后debug代码检查时如果看到本该是0x6b的位置变成了别的内容，就可能是发生了use-after-free，而本该是0x5a的位置如果变成了其它内容就意味着可能是use-uninitialised问题。更多的poison字节定义参见以下文件：
    /lib/modules/$(uname -r)/build/include/linux/poison.h

（图）SLUB对象的格式
* 绿色的 Payload表示分配出去的 slub object；
* slub debug机制需要占用额外的内存，比如 Red zone，还有，为了追溯 slub object的分配和释放过程，需要额外的空间来存放 stack trace，即图中的 Tracking/Debugging；
* 图中的 FP是 Free Pointer的缩写，处于 free状态的 object是以链表的形式串在一起的，FP就是链表指针。

怎样开启slub debug

Slub本身包含了完整的debug功能，缺省是关闭的，需要的时候打开就行了。

开启slub debug有两种方式：

  1. 【启动时开启】
    在kernel command line中加入以下参数：
    slub_debug=<Debug-Options>,<slab name>
    它会在重启时生效。
    注：
    slub_debug后面不跟任何参数表示打开所有的debug功能；
    slub_debug=<Debug-Options> 对所有的slab打开指定的debug options；
    slub_debug=<Debug-Options>,<slab name> 对指定的slab打开指定的debug options；
    slub_debug=,<slab name> 对指定的slab打开所有的debug options。
  2. 【运行中开启】
    在运行系统上可以通过以下文件对指定的slab打开指定的debug option：
    /sys/kernel/slab/<slab name>/<debug_file>

Debug options如下：

debug option sysfs debug file 功能
F sanity_checks 激活完整性检查功能，在特定的环节比如free的时候增加各种条件判断，验证数据是否完好。
Z red_zone 用于检测overrun。通过在slub object后面插入一块额外的红色区域（橄榄球术语），一旦进入就表示有错。
P poison 用于检测use-after-free和use-uninitialised。给slub对象填充特征字符，比如在分配时填充0x5a，在释放时填充0x6b，根据特征字符是否被覆盖来检测是否出错。更多的poison字节定义参见： /lib/modules/$(uname -r)/build/include/linux/poison.h
U store_user 在slub object后面添加一块额外的空间，记录调用alloc/free的stack trace
T trace 在slub object alloc/free时，向系统日志中输出相关信息，包括stack trace

开启debug option会降低系统性能，所以尽量只开启必要的选项。

  • 如果slab出现data corruption问题，可以考虑read_zone，poison，store_user，sanity_checks；
  • 如果某个slab的大小持续疯涨，则可能是leak（内存泄露），可以开启trace，观察统计slab的alloc/free情况，寻找线索。
    对于内核内存泄漏问题，还有另一个工具可供选用，详见：用KMEMLEAK检测内核内存泄漏

在kernel commandline中开启slub debug与在运行系统上开启是有区别的。有些debug option不能在运行系统上开启，比如red_zone、store_user需要额外的存储空间来保存debug信息，如果不是从一开始就开启，那么以前分配出去的slub对象就没有debug数据区，会导致对齐问题，而且debug代码也很难分辨新老slub对象；再比如poison，如果不是从一开始就开启，那么以前分配出去的slub对象就没有填充特征字符，debug代码也辨别不了哪些slub对象是有填充的、哪些是没有填充的。所以，在运行系统上开启slub debug，如果指定的slab里面已经有了object，那么只能动态开启sanity_checks和trace，惟有当指定的slab还是空的，其它的debug option才可以动态开启。我们实际使用的时候，尽管去试好了，如果某个debug option不允许动态开启，命令就不会成功，比如：

 

要进行slub debug，有一个重要特性不可不知，那就是slab merging。

Slab merging

很多slab的大小和参数是相似的，slub会把这些不同的slab合并到一起，好处是可以减少内存碎片，提高内存使用效率，这个称为slab merging（合并）。

怎么知道一个slab有没有发生合并呢？通过查看以下文件：
/sys/kernel/slab/<slab name>/aliases
aliases表示参与合并的slab的数量（自己除外），如果大于0就意味着发生了合并。

slabinfo工具（见下一节的介绍）可以具体列出哪些slab合并到了一起：

Slab merging会干扰debug，因为不同的slab合并到了一起，出了问题以后很难分辨是哪一个slab导致的。关闭slab merging的方法有两个：

  • 在kernel command line中加入“slub_nomerge”；
  • 开启slub debug之后，slab merging就会自动关闭。如果slub_debug指定了某个slab，那么只有指定的slab会关闭merging。
    注：最好是在启动时开启slub_debug，如果是在运行系统上通过sysfs开启slub debug，那么之前已经合并的那些slab仍然会保持合并状态。
slabinfo工具

随内核源程序提供了一个slabinfo工具，但是需要自己手工编译。源程序的位置是在源代码树下的 tools/vm/slabinfo.c，编译方法是：
$ gcc -o slabinfo tools/vm/slabinfo.c
或者进入 tools/vm 目录下直接执行make：
$ make slabinfo

slabinfo工具能做的事情见它的帮助信息：

 

参考资料：

https://www.kernel.org/doc/Documentation/vm/slub.txt
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-kernel-slab
https://lwn.net/Articles/340267/
https://gitlab.eurecom.fr/oai/odroid-linux-3.10.y-rt/commit/4c13dd3b48fcb6fbe44f241eb11a057ecd1cba75
一个实例分析

 

内存

怎样诊断slab泄露问题

Slab allocator是Linux kernel的内存分配机制，各内核子系统、模块、驱动程序都可以使用，但用完应该记得释放，忘记释放就会造成“内存泄露”(memory leak)。如果导致泄露的代码使用率很低倒也罢了，若是使用率很高的话，系统的内存会被迅速耗尽。

在以下案例中，132 GB 内存，仅剩21 GB空闲，还有16 GB的交换区被用掉了，显然内存使用相当紧张，而内存的主要去向是slab，slab用了89 GB，其中不可回收的部分(SUnreclaim)就占了88 GB：

再细看/proc/slabinfo，发现“size-4096”占用了84 GB之多（21720567*4096）：

通常Slab的名字就表明了其用途，比如”inode_cache”、”dentry”什么的，根据发生泄露的slab cache的名字，大致就知道是哪个子系统或模块的问题，然而本例比较复杂，因为从”size-4096″的名称完全看不出slab cache的用途。

即便从名字知道了是哪个子系统的问题，为了进一步定位故障点，我们还要看到具体是哪些函数、哪些代码在分配内存才行。要如何诊断此类问题呢？

首先取决于kernel用的是slab还是slub，slab其实是一个统称，Linux kernel自2.6.23之后就已经从Slab进化成Slub了，它自带原生的诊断功能，比Slab更方便。判断kernel是否在使用slub有一个简单的方法，就是看/sys/kernel/slab目录是否存在，如果存在的话就是slub，否则就是slab。SLUB的故障诊断请参考以下文章：如何诊断SLUB问题

SLAB

如果是slab的话，有两种常见方法：一是利用debug kernel的slab leak辅助功能，二是利用systemtap等工具。参见https://access.redhat.com/solutions/358933

使用kernel的DEBUG_SLAB_LEAK功能

这需要kernel编译的时候打开了”CONFIG_DEBUG_SLAB_LEAK”选项才行，默认是没打开的。

对RHEL或CentOS来说，debug kernel打开了此编译选项，可以安装名为kernel-debug-*的rpm软件包，然后重启系统并选择此debug kernel即可。

完成后/proc目录下会出现一个名为slab_allocators的文件，里面会记录类似如下的slab分配的信息，注意观察是什么代码在分配slab，有助于找到可疑的泄漏点。缺点是只记录了直接调用的函数，没有完整的backtrace：

使用systemtap

除了使用debug kernel之外，还有个方法就是用systemtap，对内核适当的位置植入探针，有助于找到可疑的slab分配，这需要对内核有一定的了解才行。

普通的slab cache是通过kmem_cache_alloc来分配的，可以用现成的systemtap probe vm.kmem_cache_alloc进行观测。但是在本例中不适用，因为本例中”size-4096″属于slab里的general purpose cache，是供kmalloc()使用的，所以systemtap应该针对kmalloc()进行探测，这里有一个现成的脚本 “kmalloc-top“，它的原理是对__kmalloc()下探针，记录backtraces，因为__kmalloc是实现kmalloc()的核心函数，有的代码会直接调用__kmalloc，所以探测它而不是kmalloc()才不会有遗漏。以上的脚本没有记录kmalloc的size，所以我修改了一下，加上了kmalloc size，修改过的内容如下：

以root身份执行：

间隔一段时间再ctrl-c退出，看到结果如下：

可以看到，大量的size-4096分配来自内核模块”sisips”，有理由对它产生怀疑。（因为这是Symantec的内核模块，系统上没有它的debuginfo，所以systemtap解析不了它的backtrace符号，只能显示出16进制的地址）。为了验证该模块是否真的导致了内存泄露，可以暂时禁用它，观察/proc/slabinfo看size-4096是否停止疯涨，如果停了，显然该模块就有问题了。

另一种方法：kmemleak

检测内核内存泄漏还有另一种方法，就是利用kmemleak工具，它并不是针对某一个slab，而是针对所有的内核内存。详见：
用KMEMLEAK检测内核内存泄漏

crash分析

x86发生无法恢复的硬件故障之后…

x86发生无法恢复的硬件故障之后，会触发中断通知操作系统，相关的中断类型主要有两个：

另外还有两个必须提到：

  • PCIe AER – Advanced Error Reporting，这是PCIe的新特性，发生故障时可以通过中断报告故障的详细信息，需要硬件、BIOS和driver的支持才行，但现在仍有许多硬件不支持。
  • SMI – System Management Interrupt，这是给BIOS/firmware使用的一个特殊中断，这个中断不是直接给OS用的。触发SMI中断以后，系统进入SMM模式-System Management Mode，BIOS/firmware在这种特殊模式下进行电源管理、硬件故障处理等工作。在新的APEI(ACPI Platform Error Interface)标准下，硬件故障触发的中断可以不直接通知OS，而先通过SMI进入BIOS/firmware，让BIOS/firmware可以先行处理硬件故障，视情况再决定是否通知OS继续处理。这种模式称为Firmware First Model，在新的kernel上默认是打开的，可以这样检查：
    $ dmesg | grep -i apei
    [ 1.020287] GHES: APEI firmware first mode is enabled by WHEA _OSC.

发生无法恢复的硬件故障之后，硬件直接触发中断，而不是kernel或driver通过指令触发的。那么触发的是哪一种类型的中断呢？

  • 如果处于Firmware First Model(见上文SMI段落中的解释)
    先通过SMI中断进入BIOS/firmware，BIOS/firmware对故障进行处理之后再决定是否以中断的方式通知OS，并确定中断的类型。
  • 如果处于OS Native Model（即Firmware First Model关闭的情况）
    • CPU/memory/chipset的无法恢复的故障通常触发MCE中断；
    • I/O故障可能触发PCIe AER中断，前提是软硬件都支持；
    • 其它硬件故障统统触发NMI中断。

MCE的中断优先级最高，是专为硬件故障诊断而设计的，包含了关于故障的详细信息，有助于定位故障点，它并不能涵盖所有的故障类型，限于 memory, cpu cache 和 system bus。其它常见的故障比如I/O卡通常不触发MCE。

如果软硬件都支持的话，PCIe的故障会触发AER中断，它是专为PCIe硬件故障诊断而设计的，包含了故障的详细信息，方便诊断。但许多硬件尚不支持AER。

除此之外的各种无法恢复的硬件故障统统触发NMI中断。使用NMI的缺点是NMI Status and Control Register仅有的单字节状态无法精确指示故障位置，信息量很小，很难定位故障点，毕竟NMI不是专为处理硬件故障设计的。

与小型机相比，x86的硬件故障处理机制还存在很大的不足：
小型机上发生无法恢复的硬件故障会触发一个单一的中断，只要触发这个中断就可以断定是硬件故障，并且伴随中断提供了充分的故障信息，便于定位故障。不像x86这样有多种中断类型的可能，MCE和AER倒也罢了，最后所有其它类型的硬件故障都归入NMI，而NMI是一个过度使用的公用中断，软件也用、硬件也用，perf profiling也用，watchdog也用，而且NMI本不是专为故障诊断设计的，提供的故障信息量非常少，使得故障定位很难；即使是专门为方便故障诊断而设计的MCE和AER，在实践中定位故障也不容易，除非BIOS遵照规范提供了详尽的硬件槽位信息，这在多数通用机上没有做到，有些专用设备比如磁盘阵列什么的，为了方便售后服务在BIOS/firmware上作了很多工作，这才使得MCE和AER的故障定位容易了些。总的来说，x86的硬件故障处理机制像是打补丁拼凑出来的，缺乏整体性，还有漏洞，而且标准又不是强制性的，各厂商的产品都有差异，使得本来就漏洞百出的机制又打了折扣。Intel x86的RAS只是看上去很美而已。

注：SMI还可以被服务器用于电源管理、监测等功能，比如HPE Proliant Server的BIOS就把SMI用于CPU耗电监测(Processor Power and Utilization Monitoring)和内存故障预警(Memory Pre-Failure Notification)等。

注：我们在讨论“x86发生无法恢复的硬件故障”这个题目的时候，请注意触发中断是在硬件层面上发生的，某个硬件故障直接通过硬件针脚触发中断，并不是kernel或driver通过指令触发中断。虽然kernel和driver也可以通过指令触发NMI或SMI，但那是另一个话题–即“kernel或driver认为有故障而故意触发NMI或SMI”–我们在此不予讨论。

x86 CPU的中断优先级
x86 CPU的中断优先级

 

性能工具、进程管理

理解Linux load average的误区

uptime和top等命令都可以看到load average指标，从左至右三个数字分别表示1分钟、5分钟、15分钟的load average：

Load average的概念源自UNIX系统，虽然各家的公式不尽相同，但都是用于衡量正在使用CPU的进程数量和正在等待CPU的进程数量，一句话就是runnable processes的数量。所以load average可以作为CPU瓶颈的参考指标，如果大于CPU的数量，说明CPU可能不够用了。

但是，Linux上不是这样的！

Linux上的load average除了包括正在使用CPU的进程数量和正在等待CPU的进程数量之外，还包括uninterruptible sleep的进程数量。通常等待IO设备、等待网络的时候，进程会处于uninterruptible sleep状态。Linux设计者的逻辑是，uninterruptible sleep应该都是很短暂的，很快就会恢复运行，所以被等同于runnable。然而uninterruptible sleep即使再短暂也是sleep，何况现实世界中uninterruptible sleep未必很短暂，大量的、或长时间的uninterruptible sleep通常意味着IO设备遇到了瓶颈。众所周知，sleep状态的进程是不需要CPU的，即使所有的CPU都空闲，正在sleep的进程也是运行不了的，所以sleep进程的数量绝对不适合用作衡量CPU负载的指标，Linux把uninterruptible sleep进程算进load average的做法直接颠覆了load average的本来意义。所以在Linux系统上，load average这个指标基本失去了作用，因为你不知道它代表什么意思，当看到load average很高的时候，你不知道是runnable进程太多还是uninterruptible sleep进程太多，也就无法判断是CPU不够用还是IO设备有瓶颈。

参考资料：https://en.wikipedia.org/wiki/Load_(computing)
“Most UNIX systems count only processes in the running (on CPU) or runnable (waiting for CPU) states. However, Linux also includes processes in uninterruptible sleep states (usually waiting for disk activity), which can lead to markedly different results if many processes remain blocked in I/O due to a busy or stalled I/O system.“

源代码：

 

 

 

IPC、读核笔记

Linux kernel spinlock使用不当的后果

spinlock(自旋锁)是内核中最常见的锁，它的特点是：等待锁的过程中不休眠，而是占着CPU空转，优点是避免了上下文切换的开销，缺点是该CPU空转属于浪费，spinlock适合用来保护快进快出的临界区。

spinlock有很多限制条件，其中最重要的是，持有spinlock的CPU不能被抢占，持有spinlock的代码不能休眠。如果违反，会发生死锁，后果很严重。持有spinlock的代码不能休眠，这一条是开发者编写内核程序使用spinlock的时候要人工保证的。而持有spinlock的CPU不能被抢占是由spinlock的API本身提供保证，出于效率的考虑，spinlock的API提供了多种选择，对抢占的防止程度也不一样，开发者在选用的时候需要谨慎，下文对此详细展开。

Linux内核提供了多种spinlock的API，其中最常用的是：
spin_lock/spin_unlock — 禁止内核抢占
spin_lock_irq/spin_unlock_irq — 禁止内核抢占并屏蔽中断
spin_lock_irqsave/spin_unlock_irqrestore — 禁止内核抢占并屏蔽中断，事先保存中断屏蔽位并事后恢复原状

spin_lock()禁止了内核抢占，但是没有屏蔽中断，意味着持有该spinlock的CPU有可能被中断抢占。如果你的某段内核代码选用了spin_lock()，就必须保证这段代码不会被任何中断处理程序调用，否则就会发生死锁（参见后文的一个实际发生的案例）。如果某段内核代码有可能被中断处理程序调用，那就只能选择spin_lock_irq或spin_lock_irqsave。

下面是一个刚发生的实际案例，SLES11 SP4的系统失去响应，kdump生成了vmcore，分析过程中发现以下backtraces揭示了原因：

我来解释一下，上面的backtraces意思是：CPU 2上正在运行的进程是”kswapd0″（kswapd0是负责swapping的内核线程），它正在压缩dcache以便腾出一些空闲内存，当它执行到__shrink_dcache_sb()的时候被一个中断抢占了CPU，（注意被中断抢占的进程不会离开当前CPU，不会有机会到其它CPU上运行，只能等中断处理结束之后把CPU交还给它），中断处理程序是bnx2x驱动模块（注意看[]，表示的是内核模块），它发现内存不够，于是自动清理内存，最终也走到了压缩dcache这一步，也去调用__shrink_dcache_sb()，但是__shrink_dcache_sb()的临界区受到spinlock保护，见下面源代码第0823行，这个名为dcache_lru_lock的spinlock刚才已经被”kswapd0″进程持有了，所以中断处理程序不可能抢到，问题是持有dcache_lru_lock的”kswapd0″进程又被中断抢占了CPU，不可能继续运行，也就没机会释放掉dcache_lru_lock，这就陷入了死锁状态。

根本原因在于，既然__shrink_dcache_sb()选用了spin_lock()，就意味着设计者认为它不会被中断处理程序调用，因为spin_lock()不屏蔽中断，是不能防止中断抢占的，只要中断处理程序不调用__shrink_dcache_sb()，死锁就不会发生；如果要让__shrink_dcache_sb()可以被中断处理程序调用，那就不能选用spin_lock()，而应该用spin_lock_irq或spin_lock_irqsave。这个案例中的问题出在bnx2x驱动程序中，它在bnx2x_alloc_rx_sge() 中调用alloc_pages()时不恰当地使用了GFP_KERNEL标志，实际上应该使用GFP_ATOMIC标志，这样alloc_pages()就不会试图去主动回收内存、也就不会最终调用__shrink_dcache_sb()了。此bug记载在SUSE的bsc#975358中，在kernel 3.0.101-77中得以修复。