kmemcheck和kmemleak是linux在2.6.31版本开始对外提供的内核内存管理方面的两个检测工具，最初仅支持x86环境，时至今日已经能够支持arm环境了。其中kmemcheck主要是用于内核内存破坏检测，而kmemleak则是用于内核内存泄露检测。本文主要分析kmemcheck的实现，至于kmemleak下一篇文章再详细介绍。

为什么要有kmemcheck？古人云：“人非圣贤孰能无过”，程序员也会犯错，但是这不能作为犯错的辩解。也是由于C语言的强大，几乎可以访问所有内存，加上程序开发时的考虑不周或者疏忽等情况，极有可能操作越界或者访问了未初始化的内存空间等，导致了内存破坏或者改写，这时则需要一个能够记录导致错误的日志信息。对此，kmemcheck应运而生。

kmemcheck的设计思路是分配内存页面的同时分配等量的影子内存，所有对分配出来的内存的操作，都将被影子内存所“替代”，也就是该操作都会先通过影子内存，经检测内存操作的“合法性”后，最终才会落入到实际的内存页面中，对于所有检测出来的“非法”操作，都将会被记录下来。

其具体工作原理可以通过分配内存、访问内存、释放内存以及错误处理四个方面进行了解：（注：该描述来自于IBM工程师的一篇文章：http://www.ibm.com/developerworks/cn/linux/l-cn-kmemcheck/，鉴于确实写得好，此处就照抄过来了）

1、分配内存

对分配到的内存数据页面（分配标志中不包含 __GFP_NOTRACK，__GFP_HIGHMEM，对于 slab cache 的内存，cache 创建时标志中不包含 SLAB_NOTRACK)，kmemcheck 会为其分配相同数量的影子页面（在分配影子页面时，置位了 __GFP_NOTRACK 标志位，所以它自己不会被 kmemcheck 跟踪），数据页面通过其 page 结构体中的 shadow 指针和影子页面联系起来。然后影子页面中的每个字节会标志为未初始化状态，同时将数据页面对应的页表项中 _PAGE_PRESENT 标志位清零（这样访问该数据页面时会引发页面异常），并置位 _PAGE_HIDDEN 标志位来表明该页面是被 kmemcheck 跟踪的。

2、访问内存

由于在分配过程中将数据页面对应的页表项中的 _PAGE_PRESENT 清零了，因此对该数据页面的访问会引发一次页面异常，在 do_page_fault 函数处理过程中，如果它发现页表项属性中的 _PAGE_HIDDEN 置位了，那么说明该页面是被 Kmemcheck 跟踪的，接下来就会进入 kmemcheck 的处理流程，其中会根据该次内存访问地址所对应的影子页面中的内容来检查这次访问是否是合法的，如果是非法的那么它就会将预先设置好的一个 tasklet（该 tasklet 负责错误处理）插入到当前 CPU 的 tasklet 队列中，然后去触发一个软中断，这样在中断的下半部分就会执行这个 tasklet。接下来 kmemcheck 会将影子页面中对应本次内存访问地址的内存区域标识为初始化状态（防止同一个地址警告两次），同时将数据页面页表项中的 _PAGE_PRESENT 置位，并将 CPU 标志寄存器 TF 置位开启单步调试功能，这样当页面异常处理返回后，CPU 会重新执行触发异常的指令，而这次是可以正确执行的。但是执行该指令完毕后，由于 TF 标志位置位了，所以在执行下一条指令之前，系统会进入调试陷阱（debug trap），在其处理函数 do_trap 中，kmemcheck 又会清零该数据页面页表项中的 _PAGE_PRESENT 属性标志位（并且清零标志寄存器中的 TF 位），从而当下次再访问到这个页面时，又会引发一次页面异常。

3、释放内存

影子页面会随着数据页面的释放而被释放，因此当数据页面被释放之后，如果再去访问该页面，不会出现 kmemcheck 报警。

4、错误处理

kmemcheck 用了一个循环缓冲区（包含了 CONFIG_KMEMCHECK_QUEUE_SIZE 个元素）来记录每次的警告信息，包括警告类型，引发警告的内存地址及其访问长度，各寄存器的值和 stack trace，同时还将访问地址附近（起始地址：以 2 的 CONFIG_KMEMCHECK_SHADOW_COPY_SHIFT 次幂大小对该地址进行圆整后的值；大小：2 的 CONFIG_KMEMCHECK_SHADOW_COPY_SHIFT 次幂）的数据页面和其对应影子页面中的内容保存在记录中（由同一指令地址引发的相邻的两次警告不会被重复记录）。当前文中注册的 tasklet 被调度执行时，会将循环缓冲区中所有的记录都打印出来。

了解过kmemcheck实现原理后，下面分析一下其代码显示，其中kmemcheck模块的函数入口为kmemcheck_init()：

该函数通过early_initcall()的方式注册到linux内核初始化中，其将在kernel_init()内核线程中被调用初始化，调用路径kernel_init()->kernel_init_freeable()->do_pre_smp_initcalls()->do_one_initcall()->kmemcheck_init()，至于其注册和被调用的方式实现将在后面的kswapd内核守护线程中进行分析，这里就不赘述了。

进一步分析kmemcheck_selftest()函数实现。

该函数主要封装selftest_opcodes_all()函数；

至于selftest_opcodes_all()则主要是通过遍历selftest_opcodes[]数组列表，对CPU的操作码进行解码操作。具体的selftest_opcodes定义如下。

selftest_opcode_one()将会对selftest_opcodes[]的每项操作码信息进行解析。

该函数会调用kmemcheck_opcode_decode()对操作码解码操作，这是一个非常粗暴的解码函数实现，主要是从其他指令中区别出读写指令及其大小，返回实际指令长度以及前缀操作码。最终实际上是对读写指令做操作码检验，至于为什么在初始化函数中调用，只是做一下检验？有待考究。

kmemcheck模块初始化，实际上是没做什么事情的，只是检验一下处理器的操作码，至少从代码实现中是如此的。个人感觉是为了检验代码的有效性，直接写在初始化中，以便系统启动后就可以观察到该解析函数是否有效（以上为个人愚见）。

而实际上的kmemcheck如何实现内存检查的，接下来进行分析一下。首先是分配影子内存，该函数入口为kmemcheck_alloc_shadow()，具体实现：

该函数主要是通过kmemcheck_shadow_lookup()查找到分配的内存空间对应的影子内存，而后将影子内存相应的空间大小根据内存的目标状态进行memset标记。至此，对分配的内存页面的kmemcheck准备已经完成。

前面分析的是内存页面的kmemcheck设置，而对于小块的slab内存设置的实现则在kmemcheck_slab_alloc()中，该函数主要是在slab内存分配的时候，slab_alloc_node()、slab_alloc()或slab_post_alloc_hook()函数内被调用。具体实现如下：

此函数类似于内存页面分配时的影子内存设置一样，先行经过标志判断后，继而根据内存的情况进行影子内存设置为已初始化或者未初始化的状态。。

最后，继而分析如何触发kmemcheck检测的。kmemcheck的检测主要是借助于缺页异常处理，由于内存页面设置为不在位，所以访问内存时必将导致缺页异常，继而在异常处理中对内存的访问操作进行解析，根据影子内存的标志记录信息。该解析函数为kmemcheck_fault()，具体实现：

该函数在缺页处理函数中被调用do_page_fault()->__do_page_fault()->kmemcheck_fault()。其首先对flags寄存器及cs段寄存器进行检验，避免被PnP BIOS调用到kmemcheck的函数；继而通过kmemcheck_pte_lookup()查找具有隐藏属性的页表项，如果找不到页表项，表示这是正常的缺页异常；最后通过入参中的error_code进行判断当前引发缺页异常的是程序对内存进行何种操作，使用相应的传参调用kmemcheck_access()；函数末了，将调用kmemcheck_show()进行日志记录。

具体分析一下kmemcheck_access()的实现：

该函数通过data->busy的判断，确认是否发生了kmemcheck嵌套错误，如果是的话，kmemcheck_show_addr()先将已隐藏的内存页面设置为可见，然后通过kmemcheck_error_save_bug()记录日志信息；如果没有发生嵌套错误，接下来将设置data->busy防止嵌套，通过kmemcheck_opcode_get_primary()识别并跳过指令前缀，再是kmemcheck_opcode_decode()识别处理器的操作码；继而是两个switch-case，第一个是通过识别kmemcheck_opcode_get_primary()返回的指令操作码，进行相应的处理，而第二个则是鉴于指令无法正确识别，那么将通过使用缺页异常的数据去判断该地址及其的访问方式。最终调用 kmemcheck_read()处理内存读操作、kmemcheck_write()处理内存写操作、kmemcheck_copy()则处理内存拷贝触发的kmemcheck。这三个处理函数的实现都是大同小异，仅kmemcheck_copy()处理稍微特殊，需要分别识别处理两个地址。

接下来以kmemcheck_read()为例进行分析：

该函数主要通过给定的addr以及size进行校验判断，识别当前要检测的内存空间是否存在跨内存页面的情况，如果存在，则将空间按照页面进行划分后再行通过kmemcheck_read_strict()进行检查。

至于kmemcheck_read_strict()：

此函数先是kmemcheck_shadow_lookup()查找该地址的影子内存，继而如果确认是kmemcheck检查的内存，则会kmemcheck_save_addr()将地址信息保存到当前CPU的kmemcheck_context结构信息中；接着kmemcheck_shadow_test()检查不超过页边界的读操作，主要检查对应影子中记录的内存状态是否合法，如有错，则kmemcheck_error_save()记录错误信息、出错上下文等；最后kmemcheck_shadow_set()标记本次检查过的内存影子为“初始化”，避免二次报错。其中kmemcheck_error_save()记录日志并非是同步记录的，而是通过kmemcheck_tasklet进行异步记录的，具体的实现这里就不细致分析了。

至此，kmemcheck的内存检查代码实现分析完毕。kmemcheck的实现思路很有特色，通过一比一的内存空间开销，一对一地由影子内存去跟踪内存的使用状况。