Linux 内核的测试和调试

http://x-slam.com/linux-kernel-testing-and-debugging

Linux 内核测试哲学

不管是开源还是闭源，所有软件的开发流程中，测试是一个重要的、不可或缺的环节，Linux 内核也不例外。开发人员自测、系统测试、回归测试、压力测试，都有各自不同的目的，但是从更高一个层次上看，这些测试的最终目的又是一样的：保证软件能一直运行下去，当有新功能加进去时，要保证新功能可以正常工作。

在软件释出 release 版之前，不用回归测试就能保证稳定性，并且尽量避免在软件发布后被用户发现 bug。调试被用户发现的 bug 是一项非常浪费时间和精力的工作。因此测试是一项非常重要的工作。不像闭源和专有的操作系统，Linux 内核的开发过程是完全开放的。这种处理方式即是它的优点，也是它的缺点。多个开发者持续增加新功能、修 bug、不断集成与测试 —— 当环境有新的硬件或功能时，这种开发方式能够保证内核能持续工作。在开源项目中，开发者与用户共享测试的结果，这也是开源项目与闭源项目之间的一个很重要的差别。

几乎所有 Linux 内核开发者都是活跃的 Linux 用户。内核测试人员不一定非得是内核开发者，相反，用户和开发者如果对新增的代码不是很熟悉，他们的测试效果会比代码开发人员自己测试的效果要好很多。也就是说，开发者的单元自测能验证软件的功能，但并不能保证在其他代码、其他功能、其他软件、硬件环境下面运行时会出现什么问题。开发者无法预料、也没有机会和资源来测试所有环境。因此，用户在 Linux 内核开发过程中起到非常重要的角色。

现在我们已经了解了持续集成测试的重要性，接下来我们会详细介绍测试的知识。但在此之前，我还是向你介绍一下开发的过程，以便让大家了解它是怎么工作的，以及如何把补丁打进内核主线。

全世界共有3000多个内核开发者为 Linux 内核贡献代码，每天都有新代码添加到内核，结果是大概2个月就能产生一个release ，包括几个稳定版和扩展稳定版。新功能的开发与已发布的稳定版集成测试流程在同时进行。

关于开发流程的详细描述，请参考Greg Kroah-Hartman 的 Linux 内核开发的介绍。

这份教程适合与初学者以及有经验的内核开发者，如果你想加入到内核开发者行列，那么它也适合你。有经验的开发人员可以跳过那些介绍基础测试和调试的章节。

这份教程介绍如何测试和调试 Linux 内核、工具、脚本以及在回归测试和集成测试中使用的调试机制。另外，本文还会介绍如何使用 git 把针对一个 bug 的补丁分离出来，再介绍把你的补丁提交到内核的邮件列表之前需要做些什么。我将会使用 Linux PM 作为测试它调试的对象。尽管本文讨论的是 Linux 内核，但是介绍的方法也适用于任何其他软件开发项目。

配置开发与测试的系统
第一步，找一个满足你需求的开发环境，x86-64 是一个比较理想的选择，除非你必须用特别的架构。

第二步，安装 Linux 发行版，我推荐 Ubuntu，所以本教程会介绍基于 Ubuntu 的配置过程。你可以参考如何使用 Ubuntu 来安装一个 Ubuntu 系统。

在开发和测试环境，最好要保证你的 boot 分区有足够的空间来存放内核文件。你可以为 boot 分区留下 3GB 空间，或把 boot 分区直接放到根目录下，这样 boot 分区可以使用整个磁盘的空间。

安装好操作系统后，确保 root 用户可用，确保你的用户身份可以使用 sudo 命令。你的系统也许已经安装了 build-essential，它是编译内核必备的软件包，如果没安装，运行下面的命令：

sudo apt-get install build-essential

然后运行下面的命令，保证你的系统能够交叉编译内核。下面的 ncurses-dev 安装包是运行 make menuconfig 命令必须用到的。

sudo apt-get install binutils-multiarch
sudo apt-get install ncurses-dev
sudo apt-get install alien

然后安装一些每个内核开发者都会用到的工具包：

sudo apt-get install git
sudo apt-get install cscope
sudo apt-get install meld
sudo apt-get install gitk

如果你喜欢把内核通过交叉编译以支持非 x86_64 架构的环境，请参考在 x86_64 上交叉编译 Linux 内核。

稳定的内核
使用 git 克隆一个稳定的内核，然后编译安装。你可以参考Linux 内核结构来找到最新的稳定版和开发主线。

git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

上面的步骤将会创建一个新的目录，名为 linux-stable，并把源码下载到里面。

你也可以直接下载压缩包并解压出源码，无需使用 git：

tar xvf linux-3.x.y.tar.xz

编译安装稳定版内核
如果你用 git 下载源码，就执行以下命令：

cd linux-stable
git checkout linux-3.x.y

如果是直接下载压缩文件，用以下命令进入源码目录：

cd linux-3.x.y

如果你想把内核安装到自己的系统上，最安全的方法是使用你安装好的发行版拥有的配置文件。你可以在 /boot 目录找到当前发行版的内核配置文件：

cp /boot/config-3.x.y-z-generic .config

运行下面的命令，可以在当前内核配置的基础上修改一些小地方，然后产生新的内核配置文件。比如说新的内核比你的 Ubuntu 发行版自带的内核多了些新功能，而你正好需要用到它们，这个时候你就要修改配置了。

make oldconfig

完成配置后，就可以编译了：

make all

完成编译后，安装这个新的内核：

sudo “make modules_install install”

上面的命令安装新内核，并把新内核作为启动项添加到 grub 文件（LCTT：就是你下次开机时会多出一个开机选项）。好了你可以重启电脑，然后选择新的内核启动系统。等等！先别冲动，在重启电脑之前，我们保存下编译内核产生的日志，用于比较和查找错误（如果有错误发生的话）：

dmesg -t > dmesg_current
dmesg -t -k > dmesg_kernel
dmesg -t -l emerg > dmesg_current_emerg
dmesg -t -l alert > dmesg_current_alert
dmesg -t -l crit > dmesg_current_alert
dmesg -t -l err > dmesg_current_err
dmesg -t -l warn > dmesg_current_warn

正常的话，dmesg 不会输出 emerg, alert, crit 和 err 级别的信息。如果你不幸看到这些输出了，说明内核或者你的硬件环境有问题。

再介绍一些重启前的需要执行的操作。谁也不能保证新内核能够正常启动，所以请不要潇洒地把老内核删除，至少保留一个稳定可用的内核在系统上。修改一下 /etc/default/grub 文件：

使用 earlyprink=vga 作为内核启动选项，把系统早期启动的信息打印到显示屏上：

GRUB_CMDLINE_LINUX=”earlyprink=vga”

将 GRUB_TIMEOUT 的值设置成10秒到15秒之间的值，保证在开机启动的时候你有足够的时间来选择启动哪个内核：

取消对 GRUB_TIMEOUT 的注释，并把它设置为10：GRUB_TIMEOUT=10

注释掉 GRUB_HIDDEN_TIMEOUT 和 GRUB_HIDDEN_TIMEOUT_QUIET

运行 update-grub 命令，更新 /boot 目录下的 grub 配置文件：

sudo update-grub

现在可以重启系统了。新内核起来后，比较新老内核的 dmesg 信息，看看新的内核有没有编译错误。如果新内核启动失败，你需要通过老内核启动系统，然后分析下为什么失败。

跟上节奏，永不落后（编译最新版内核）
如果你想开上内核快车道，追求与时俱进，那就去下载 mainline 状态的内核或 linux-next 状态的内核（LCTT：读者可进入 kernel.org 获取代码，linux 代码被分为4种状态：mainline, stable, longterm, linux-next）。安装测试 mainline 状态或 linux-next 状态的内核，你就可以在正式发布之前帮助内核找到并修复里面的 bug。

mainline 状态的内核源码：

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

linux-next 状态的内核源码：

git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

编译安装这两种内核的步骤与编译安装稳定版内核一样。按之前讲过的步骤来就行了。

打补丁
Linux 内核的补丁是一个文本文件，包含新源码与老源码之间的差异。每个补丁只包含自己所依赖的源码的改动，除非它被特意包含进一系列补丁之中。打补丁方法如下：

patch -p1 < file.patch
git apply --index file.patch

两种方法都可以打补丁。但是，如果你要打的补丁包含一个新文件，git 命令不能识别这个新增的文件，也就是说这个新文件在 git 里面属于 untracked 文件（LCTT：玩 git 的人对这个会比较熟悉，就是文件处于未被跟踪的状态，你需要使用 git add 命令将文件放入暂存区）。git diff 命令不会将这个文件的增量显示出来，并且 git status 命令会显示这个文件处于 untracked 状态。

大多数情况下，有个没被跟踪的文件，对于编译安装内核来说没什么问题，但是 git 操作就会出现一些问题了： git reset –hard 命令不会删除这个新加的文件，并且接下来的 git pull 操作也会失败。你有多种选择来避免上面所说的状况：

选项1，不跟踪这个新文件：

如果打补丁后新添加了文件，在 git reset –hard 前使用 git clean 命令来删除没有被跟踪的文件。举个例子，git clean -dfx 命令会强制删除未被跟踪的目录和文件，忽略在 .gitigniore 文件内规定的文件。如果你不在乎哪些文件会被删除，你可以使用 -q 选项让 git clean 命令进入安静模式，不输出任何处理过程。

选项2，跟踪新文件：

你可以在使用 git apply –index file.patch 命令后让 git 跟踪打完补丁后新产生的文件（LCTT：使用 git add 命令），就是让 git 把文件放入 index 区域。做完这个后，git diff 命令会将新文件的增量打印出来，git status 也会显示者这是一个正常的新增文件。

基本测试
安装好内核后，试试能不能启动它。能启动的话，检查 dmesg 看看有没有隐藏的错误。试试下面的功能：

网络（Wifi 或者网线）是否可用？
ssh 是否可用？
使用 ssh 远程传输文件。
使用 git clone 和 git pull 命令。
用用网络浏览器。
查看 email。
使用 ftp, wget 等软件下载文件。
播放音频视频文件。
连上 USB 鼠标等设备。

检查内核日志
使用 dmesg 查看隐藏的问题，对于定位新代码带来的 bug 是一个好方法。一般来说，dmesg 不会输出新的 crit, alert, emerg 级别的错误信息，也不应该出现新的 err 级别的信息。你要注意的是那些 warn 级别的日志信息。请注意 warn 这个级别的信息并不是坏消息，新代码带来新的警告信息，不会给内核带去严重的影响。

dmesg -t -l emerg
dmesg -t -l crit
dmesg -t -l alert
dmesg -t -l err
dmesg -t -l warn
dmesg -t -k
dmesg -t

下面的脚本运行了上面的命令，并且将输出保存起来，以便与老的内核的 dmesg 输出作比较（LCTT：老内核的 dmesg 输出在本系列的第二篇文章中有介绍）。然后运行 diff 命令，查看新老内核 dmesg 日志之间的不同。这个脚本需要输入老内核版本号，如果不输入参数，它只会生成新内核的 dmesg 日志文件后直接退出，不再作比较（LCTT：话是这么说没错，但点开脚本一看，没输参数的话，这货会直接退出，连新内核的
dmesg 日志也不会保存的）。如果 dmesg 日志有新的警告信息，表示新发布的内核有漏网之“虫”，这些 bug 逃过了自测和系统测试。你要看看，那些警告信息后面有没有栈跟踪信息？也许这里有很多问题需要你进一步调查分析。

dmesg 测试脚本

压力测试
执行压力测试的一个好办法是同时跑三四个内核编译任务。下载各种版本的内核，同时编译它们，并记录时间。比较新内核跑压力测试和老内核跑压力测试所花的时间，然后可以定位新内核的性能。如果新内核跑压力测试的时间比老内核的更长，说明新内核的部分模块性能退步了。性能问题很难调试出来。第一步是找出哪里导致的性能退步。同时跑多个内核编译任务对检测内核整体性能来说是个好方法，但是这种方法涵盖了多个内核模块，比如内存管理、文件系统、DMA、驱动等（LCTT：也就是说，这种压力测试没办法定位到是哪个模块造成了性能的下降）。

time make all

内核测试工具
我们可以在 Linux 内核本身找到多种测试方法。下面介绍一个很好用的功能测试工具集： ktest 套件

ktest 是一个自动测试套件，它可以提供编译安装启动内核一条龙测试服务，也可以跑交叉编译测试，前提是你的系统有安装交叉编译所需要的软件。ktest 依赖于 flex 和 bison。详细信息请参考放在 tools/testing/ktest 目录下的文档，你可以自学成材。另外还有一些参考资料教你怎么使用 ktest：

ktest-eLinux.org

tools/testing/selftests 套件
我们来玩玩自测吧。内核源码的多个子系统都有自己的自测工具，到目前为止，断点、cpu热插拔、efivarfs、IPC、KCMP、内存热插拔、mqueue、网络、powerpc、ptrace、rcutorture、定时器和虚拟机子系统都有自测工具。另外，用户态内存的自测工具可以利用 testusercopy 模块来测试用户态内存到内核态的拷贝过程。下面的命令演示了如何使用这些测试工具：

编译测试：

make -C tools/testing/selftests

测试全部：（有些测试需要 root 权限，你需要以 root 用户登入系统然后运行命令）

make -C tools/testing/selftests run_tests

只测试单个子系统：

make -C tools/testing/selftests TARGETS=vm run_tests

tools/testing/fault-injection 套件
在 tools/testing 目录下的另一个测试套件是 fault-injection。failcmd.sh 脚本用于检测 slab 和内存页分配器的错误。这些工具可以测试内核能否很好地从错误状态中恢复回来。这些测试需要用到 root 权限。下面简单介绍了一些当前能提供的错误检测方法。随着错误检测方法的增加，这份名单也会不断增长。最新的名单请参考 Documentation/fault-injection/fault-injection.txt 文档。

failslab （默认选项）

产生 slab 分配错误。作用于 kmalloc(), kmemcachealloc() 等函数（LCTT：产生的结果是调用这些函数就会返回失败，可以模拟程序分不到内存时是否还能稳定运行下去）。

fail_page_alloc

产生内存页分配的错误。作用于 allocpages(), getfree_pages() 等函数（LCTT：同上，调用这些函数，返回错误）。

fail_make_request

对满足条件（可以设置 /sys/block//make-it-fail 或 /sys/block///make-it-fail 文件）的磁盘产生 IO 错误，作用于 generic_make_request() 函数（LCTT：所有针对这块磁盘的读或写请求都会出错）。

fail_mmc_request

对满足条件（可以设置 /sys/kernel/debug/mmc0/fail_mmc_request 这个 debugfs 属性）的磁盘产生 MMC 数据错误。

你可以自己配置 fault-injection 套件的功能。fault-inject-debugfs 内核模块在系统运行时会在 debugfs 文件系统下面提供一些属性文件。你可以指定出错的概率，指定两个错误之间的时间间隔，当然本套件还能提供更多其他功能，具体请查看 Documentation/fault-injection/fault-injection.txt。 Boot 选项可以让你的系统在 debugfs 文件系统起来之前就可以产生错误，下面列出几个 boot 选项：

failslab=
fail_page_alloc=
fail_make_request=
mmc_core.fail_request=[interval],[probability],[space],[times]

fault-injection 套件提供接口，以便增加新的功能。下面简单介绍下增加新功能的步骤，详细信息请参考上面提到过的文档：

使用 DECLARE_FAULT_INJECTION(name) 定义默认属性；

详细信息可查看 fault-inject.h 中定义的 struct fault_attr 结构体。

配置 fault 属性，新建一个 boot 选项;

这步可以使用 setup_fault_attr(attr, str) 函数完成，为了能在系统启动的早期产生错误，添加一个 boot 选项这一步是必须要有的。

添加 debugfs 属性；

使用 fault_create_debugfs_attr(name, parent, attr) 函数，为新功能添加新的 debugfs 属性。

为模块设置参数；

为模块添加一些参数，对于配置错误属性来说是一个好主意，特别是当新功能的应用范围受限于单个内核模块的时候（LCTT：不同内核，你的新功能可能需要不同的测试参数，通过设置参数，你的功能可以不必为了迎合不同内核而每次都重新编译一遍）。

添加一个钩子函数到错误测试的代码中。

should_fail(attr, size) —— 当这个钩子函数返回 true 时，用户的代码就应该产生一个错误。

应用程序使用这个 fault-injection 套件可以指定某个具体的内核模块产生 slab 和内存页分配的错误，这样就可以缩小性能测试的范围。

自动测试工具
这里列出一些能满足不同需求的测试工具供你选择。本小节只是简单介绍个大概，并不提供详细操作指南。

AuToTest

AuToTest 是一个全自动测试框架，存在的主要目的就是测试 Linux 内核，当然也可以用来测试其他东西，比如测试一块新硬件是否能稳定工作。AuToTest 是开源软件，以 GPL 方式授权，运行于 server-client 架构（即 C/S 架构）。你可以通过配置 server 端来对运行了 client 端的系统执行初始化、运行与监测工作，也可以自己在目标系统上让 client 运行起来。另外你可以为这个测试框架添加测试用例，详情请参考AuToTest
白皮书。

Linaro Automated Validation Architecture

LAVA 自动测试框架用于自动安装于运行测试。举个例子：你在 LAVA 里面只需运行几个命令就可以跑 LTP（LCTT：Linux Test Project，中文是 Linux 测试计划，SGI发起并由IBM负责维护，目的是为开源社区提供测试套件来验证Linux的可靠性、健壮性和稳定性）。通过 LAVA 命令可以自动为你安装 LTP 所需要的所有依赖包，下载源码、编译编码、将 LTP 安装到某个独立的地方，方便卸载 LTP 时能移除所有二进制文件。安装好 LTP 后，运行 LAVA 命令时添加 ‘ltp’
选项就可以运行 LTP 测试任务了，它会将测试结果以文件方式保存下来，文件名包含测试名称、时间戳。这些测试结果可以留着供以后参考。这是个发现软件退化（如果软件退化了的话）的好方法。下面列出 LAVA 配合 LTP 使用的一些命令：

显示 LAVA 支持的测试列表：

lava-test list-tests

安装测试套件：

lava-test install ltp

运行测试：

lava-test run ltp

查看结果：

lava-test results show ltp-timestamp.0

卸载测试套件：

lava-test uninstall ltp

内核调试功能
Linux 内核本身包含很多调试功能，比如 kmemcheck 和 kmemleak。

kmemcheck

kmemcheck 是一个动态检查工具，可以检测出一些未被初始化的内存（LCTT：内核态使用这些内存可能会造成系统崩溃）并发出警告。它的功能与 Valgrind 类似，只是 Valgrind 运行在用户态，而 kmemchecke 运行在内核态。编译内核时加上 CONFIG_KMEMCHECK 选项打开 kmemcheck 调试功能。你可以阅读 Documentation/kmemcheck.txt 来学习如何配置使用这个功能，以及如何看懂调试结果。

kmemleak

kmemleak 通过类似于垃圾收集器的功能来检测内核是否有内存泄漏问题。而 kmemleak 与垃圾收集器的不同之处在于前者不会释放孤儿目标（LCTT：不会再被使用的、应该被释放而没被释放的内存区域），而是将它们打印到 /sys/kernel/debug/kmemleak 文件中。用户态的 Valgrind 也有一个类似的功能，使用 –leak-check 选项可以检测并报错内存泄漏问题，但并不释放这个孤儿内存。编译内核时使用 CONFIG_DEBUG_KMEMLEAK 选项打开 kmemcleak
调试功能。阅读 Documentation/kmemleak.txt 来学习怎么使用这个工具并读懂调试结果。

内核调试接口
Linux 内核通过配置选项、调试用的 API、接口和框架来支持动态或静态的调试。我们现在就好好学习学习这些牛逼的功能，从静态编译选项开始讲。

调试配置选项：静态编译
大部分 Linux 内核以及内核模块都包含调试选项，你只要在编译内核或内核模块的时候添加这个静态调试选项，程序运行时后就会产生调试信息，并记录在 dmesg 缓存中。

调试的 API
调试 API 的一个很好的例子是 DMA-debug，用来调试驱动是否错误使用了 DMA 提供的 API。它会跟踪每个设备的映射关系，检测程序有没有试图为一些根本不存在的映射执行“取消映射”操作，检测代码建立 DMA 映射后可能产生的“映射丢失”的错误。内核配置选项 CONFIG_HAVE_DMA_APT_DEBUG 和 CONFIG_DMA_API_DEBUG 可以为内核提供这个功能。其中，CONFIG_DMA_API_DEBUG 选项启用后，内核调用 DMA 的 API 的同时也会调用 Debug-dma
接口。举例来说，当一个驱动调用 dma_map_page() 函数来映射一个 DMA 缓存时，dma_map_page() 会调用debug_dma_map_page() 函数来跟踪这个缓存，直到驱动调用 dma_unmap_page() 来取消映射。详细内容请参考使用 DMA 调试
API 检测潜在的数据污染和内存泄漏问题。

动态调试
动态调试功能就是你可以决定在程序运行过程中是否要 pr_debug(), dev_dbg(), print_hex_dump_debug(), print_hex_dump_bytes() 这些函数正常运行起来。什么意思？当程序运行过程中出现错误时，你可以指定程序打印有针对性的、详细的调试信息。这功能牛逼极了，我们不再需要为了添加调试代码定位一个问题，而重新编译安装内核。你可以指定 CONDIF_DYNAMIC_DEBUG 选项打开动态调试功能，然后通过 /sys/kernel/debug/dynamic_debug/control
接口指定要打印哪些调试日志。下面分别列出代码级别和模块级别打印日志的操作方法：

让 kernel/power/suspend.c 源码第340行的 pr_debug() 函数打印日志：

echo ‘file suspend.c line 340 +p’ > /sys/kernel/debug/dynamic_debug/control

让内核模块在加载过程中打开动态调试功能：

使用 modprobe 命令加在模块时加上 dyndbg=’plmft’ 选项。

让内核模块的动态调试功能在重启后依然有效：

编辑 /etc/modprobe.d/modname.conf 文件（没有这个文件就创建一个），添加 dyndbg=’plmft’ 选项。然而对于哪些通过 initramfs 加载的驱动来说，这个配置基本无效（LCTT：免费奉送点比较高级的知识哈。系统启动时，需要先让 initramfs 挂载一个虚拟的文件系统，然后再挂载启动盘上的真实文件系统。这个虚拟文件系统里面的文件是 initramfs 自己提供的，也就是说你在真实的文件系统下面配置了 /etc/modprobe.d/modname.conf 这个文件，initramfs
是压根不去理会的。站在内核驱动的角度看：如果内核驱动在 initramfs 过程中被加载到内核，这个驱动读取到的 /etc/modprobe.d/modname.conf 是 initramfs 提供的，而不是你编辑的那个。所以会有上述“写了配置文件后重启依然无效”的结论）。对于这种刁民，呃，刁驱动，我们需要修改 grub 配置文件，在 kernel 那一行添加 module.dyndbg=’plmft’ 参数，这样你的驱动就可以开机启动动态调试功能了。

想打印更详细的调试信息，可以使用 dynamic_debug.verbose=1 选项。参考 Documentation/dynamic-debug-howto.txt 文件获取更多信息。

设置追踪点
到目前为止，我们介绍了多种动态和静态调试方法。静态调试选项和静态调试钩子函数（比如 DMA Debug API）需要的编译过程打开或关闭，导致了一个难过的事实：需要重新编译安装内核。而动态编译功能省去了“重新编译”这件麻烦事，但是也有不足的地方，就是调试代码引入了条件变量，用于判断是否打印调试信息。这种方法可以让你在程序运行时决定是否打印日志，但需要执行额外的判断过程。“追踪点”代码只会在程序运行过程中使用“追踪点”功能才会被触发。也就是说，“追踪点”代码与上述说的两种方法都不一样。当用不到它时，它不会运行（LCTT：动态调试的话，代码每次都需要查看下变量，然后判断是否需要打印日志；而“追踪点”貌似利用某种触发机制，不需要每次都去查看变量）。当你需要用到它时，程序的代码会把“追踪点”代码包含进去。它不会添加任何条件变量来增加系统的运行负担。

详细信息请参考布置追踪代码的小技巧。

“追踪点”的原理
追踪点使用“跳跃标签”，这是一种使用分支跳转的编码修正（code modification）技术。

当关闭追踪点的时候，其伪代码看起来时这样的：

[ code1 ]
nop
back:
[ code2 ]
return;
tracepoint:
[ tracepoint code ]
jmp back;

当打开追踪点的时候，其伪代码看起来时这样的：（注意追踪点代码出现的位置）

[ code1 ]
jmp tracepoint
back:
[ code2 ]
return;
tracepoint:
[ tracepoint code ]
jmp back;

（LCTT：咳咳，解释解释上面两段伪代码吧，能看懂的大神请忽略这段注释。不使用追踪点时，代码运行过程是：code1->code2->return结束；使用追踪点时，代码运行过程是：code1->跳到tracepoint code执行调试代码->跳回code2->return结束。两段代码的唯一区别就是第二行，前者为 nop（不做任何操作），后者为 jmp tracepoint （跳到调试代码）。）

Linux 电源管理子系统的测试
使用静态调试、动态调试和追踪调试技术，我们来跑一下磁盘的电源管理测试。当系统被挂起时，内核会为磁盘创建一个休眠镜像，使磁盘进入休眠模式，当系统重新被唤醒时，内核又利用这个休眠镜像重新唤醒磁盘。

设置挂起设备与唤醒设备需要的时间：

echo 1 > /sys/power/pm_print_times

以 reboot 模式挂起磁盘：

echo reboot > /sys/power/disk
echo disk > /sys/power/state

以 shutdown 模式挂起磁盘 —— 与 reboot 模式一样，只是重新唤醒磁盘的话还需要电源提供。

echo shutdown > /sys/power/disk
echo disk > /sys/power/state

以 platform 模式挂起磁盘 —— 能测试更多内容，比如 BIOS 挂起和唤醒，会涉及到 ACPI 功能。我们推荐你使用这种方式，把 BIOS 也拉下水陪你玩挂起和唤醒游戏。

echo platform > /sys/power/disk
echo disk > /sys/power/state

仿真环境下进行 Linux 电源管理子系统测试
Linux 电源管理子系统在仿真环境下提供5种测试方式。这些方式仅仅在内核各层之间运行休眠的代码而不是真正的让系统进入休眠状态。有些平台不能挂起系统，比如说我们需要模拟飞机的飞行环境，这时候使用这种仿真环境就非常有用处了。

freezer – 测试停掉处理器：

echo freezer > /sys/power/pm_test
echo platform > /sys/power/disk
echo disk > /sys/power/state

devices – 测试停掉处理器以及挂起设备：

echo devices > /sys/power/pm_test
echo platform > /sys/power/disk
echo disk > /sys/power/state

platform – 测试停掉处理器、挂起设备以及平台全局控制方法(*)

echo platform > /sys/power/pm_test
echo platform > /sys/power/disk
echo disk > /sys/power/state

processors – 测试停掉处理器、挂起设备和平台全局控制方法(*)，以及关闭未启动的 CPU。

echo processors > /sys/power/pm_test
echo platform > /sys/power/disk
echo disk > /sys/power/state

core – 测试停掉处理器、挂起设备和平台全局控制方法(*)，关闭未启动的 CPU，以及挂起平台或系统的设备。注意：这个测试模式运行在 ACPI 系统。

echo core > /sys/power/pm_test
echo platform > /sys/power/disk
echo disk > /sys/power/state

Linux 电源管理子系统追踪事件
电源管理子系统在运行过程中支持多种追踪点和追踪事件。我将对如何使用这些追踪时间以及如何找到追踪信息作一个简单的介绍：

在运行时开启电源管理事件：

cd /sys/kernel/debug/tracing/events/power
echo 1 > cpu_frequency/enable
cat /sys/kernel/debug/tracing/set_event
less /sys/kernel/debug/tracing/trace

为内核启动的命令添加一个参数：

trace_event=cpu_frequency

更多信息查看 Documentation/power/basic-pm-debugging.txt 以及同目录下其他的文档。

git bisect 命令
git bisect 是一个非常有用非常强大的工具，用于将 git 上的一个 commit 分离出来。我简单过一遍它的用法。

下面是 git bisect 的用法：

git bisect start
git bisect bad   # 当前版本是坏的
git bisect good v3.14-rc6   # 上个版本是好的

一旦指定好好的版本和坏的版本，git bisect 就会开始把好坏两个版本之间的所有 commit 对半分，并将其中的一半提交 pull 下来。然后重新编译安装测试内核，并标记这个内核是好是坏。重复这个过程，知道某个你选好的 commit 被标记被好或者坏。我们可能需要测试多个内核版本，测到最后一个版本时，git bisect 会将一个 commit 标记为坏。下面的命令可以在 git bisect 分析过程中起到帮助作用：

查看 bisect 操作的过程：

git bisect log

重置 git bisect，标记错误时可以用到，保存 git log 的输出，重新操作上一次 bisect 的步骤：

git bisect reset

重放 git bisect 操作过程：

git bisect replay git_log_output

如果一个问题很清楚是在某个区域内，git bisect 命令可以定位到一个具体的内核源码树枝干上。举个例子，在调试一个镭龙显卡驱动的问题时，为 git bisect 指定 drivers/drm/radeon 参数，可以让 git bisect 只检索对 drivers/drm/radeon 里面的文件有修改的 commit。

让 git bisect 只检索内核树的某个枝干：

git bisect start drivers/drm/radeon

Linux 内核补丁测试
你试过自己写内核补丁吗？本节介绍在把你的补丁包提交到 Linux 邮箱列表之前，需要做哪些操作。另外我们还会介绍如何把它发送出去。

写好代码后，编译它。把 make 过程产生的输出保存到文档中，查看新代码有没有警告信息。找到所有的警告信息，处理掉。当你的代码编译过程没有任何不正常的输出，安装这个内核，然后启动测试。如果启动正常，查看 dmesg 里面有没于错误，与老内核生成的 dmesg 日志做个比较。运行一些压力测试，请参考我们以前讲过的测试内容。如果这个补丁用于修复某个 bug，请确保真的已经修复了。如果真的修复了，请确保能通过系统测试。找出打你补丁的模块下面的回归测试工具，运行一下。如果补丁涉及到其他架构，你需要交叉编译然后测试一下。请通过下面的目录查找测试工具：

linux_git/Documentation
linux_git/tools/testing
交叉编译参考：在 x86_64 架构上交叉编译 Linux 内核：初学者教程

如果你对你的补丁测试结果感到很满意，你就可以提交补丁了。请确保提交 commit 的信息要描述得非常清楚。要让内核维护者和其他开发者看懂补丁所修改的内容，这一点非常重要。生成补丁后，执行 scripts/checkpatch.pl 脚本，找到 checkpatch 是产生的错误或警告（如果有的话），修复它们。重新生成补丁，直到补丁通过这个脚本的测试。重新测试这个补丁。将本补丁用于其他的内核源码上，保证不会有冲突产生。

现在你做好提交补丁的准备了。先运行 scriptst/get_maintainer.pl 来确认你应该把补丁发给哪个内核维护者。注意不要以附件形式发送补丁，而是以纯文本形式粘贴在邮件里面。确保你的邮件客户端可以发送纯文本信息，你可以试试给自己发送一份补丁邮件来测试你的邮件客户端的功能。收到自己的邮件后，运行 checkpatch 命令并给自己的内核源码打上你的补丁。如果这两部都能通过，你就可以给 Linux 邮箱列表发送补丁了。使用 git send-email 命令是提交补丁最安全的方式，可以避免你的邮箱的兼容性问题。你的
.gitconfig 文件里面需要配置好有效的 smtp 服务器，详细操作参考 git 的帮助文档。

更多提交补丁的规矩，请参考下面的资料：

linux_git/Documentation/applying-patches.txt
linux_git/Documentation/SubmitChecklist
linux_git/Documentation/SubmittingDrivers
linux_git/Documentation/SubmittingPatches
linuxgit/Documentation/stablekernel_rules.txt
linuxgit/Documentation/stableapi_nonsense.txt

下面是一些内核测试教程的资料：

USB Testing on Linux
Linux Kernel Tester’s Guide Chapter2
Linux Kernel Tester’s Guide
Testing resources at eLinux.org
eLinux Debugging Portal

内核测试套件和项目
除我们讨论过的测试资源之外，这里还有很多测试项目值得介绍，包括开源的和厂家自己提供的。这些项目每一个都是针对特定领域的，比如嵌入式或者企业自己使用。我们简单过一下。

Linux 测试项目（LTP）测试套件是一系列工具的集合，用于测试内核的可靠性、健壮性和稳定性。你可以为这个项目添加自己的测试代码，并且 LTP 项目欢迎你贡献自己的代码。runltp 脚本默认情况下会测试下面的子系统：

文件系统压力测试
磁盘 IO 测试
内存管理压力测试
IPC（进程间通信）测试
调度器测试
命令的功能性验证测试
系统调用功能验证测试

LTP-DDT 是一个基于 LTP 的测试应用（LCTT：就是 LTP 的阉割版么），专注于测试嵌入式设备驱动。

Linux Driver Verification 这个项目的目标是提高 Linux 设备驱动的质量，它为设备驱动验证开发了集成环境平台，并且利用与时俱进的研究来增强验证工具的质量。

一致性测试
如果你有将某个 Unix 平台下的应用一直到另一个平台的经验，你就能理解
Linux Standard Base (LSB) 和 LSB 一致性测试套件的重要性了。LSB 是 Linux Foundation 工作组创建的用于降低支持不同 Linux 平台所需要的开销，方法就是通过降低不同 Linux 发行版之间的差别，保证应用在不同发行版之间的可移植性。前事不忘后事之师，Unix 世界的分歧在 Linux 世界一定要避免。这就是为什么你可以把一个 rpm 包转化成 deb 包后还能安装并正常运行的秘密。

静态分析工具
静态分析之所以会被称为“静态分析”，是因为这些工具只分析代码，并不执行它们。分析 Linux 内核代码的静态分析工具有很多，Sparse 是 Linus Torvalds 写的专门用于检查内核静态类型的工具。它是一个语义检查器，会为 C 语言的语义建立语义检析树，执行惰性类型评估。内核编译系统支持 sparse，并且为编译内核的命令提供开启 sparse 的选项。

为内核所有需要重新编译的 C 文件执行 sparse 语义检查：

make C=1 allmodconfig

为内核所有 C 文件（即使不需要重新编译）执行 sparse 语义检查：

make C=2 allmodconfig

Sparse 的资源：

Sparse Archive
Sparse How To

Smatch 分析程序代码的逻辑错误。它可以检测到诸如“为一个没锁上的 spinlock 执行解锁”的逻辑错误。内核源码支持 smatch：

在 Linux 内核中运行 smatch：

make CHECK=”~/path/to/smatch/smatch -p=kernel” C=1 bzImage modules | tee warns.txt

请参考下面的资料来获取和编译 smatch。需要注意的是 smatch 是个正在发展的项目，架构会不断变化。

Smatch

那么我们该怎么处理 Sparse 和 Smatch 所发现的语义和逻辑上的错误呢？一些错误可以被分离为日常问题或模块问题，可以轻易被解决。但是有些语义错误涉及到全局，因为剪切粘贴了一些代码。在一些环境中，当一些接口函数被废弃不再使用，或者仅仅做了写微小的修改，你就需要大规模更新源码。这时候你需要 Coccinelle 来帮忙。，Coccinelle 使用 SmPL 语言（语义包语言）来为 C 代码提供匹配和转换代码的功能。Coccinelle 的从一开始就作为 Linux 的附属产品持续发展的。

举个例子：foo(int) 函数突然变成 foo(int, char *) 函数，多出了一个输入参数（可以把第二个参数置为 null）。所有调用 foo() 函数的代码都需要更新了，这可能是个悲摧的体力活。但是使用 Coccinelle 的话，这项工作瞬间变得轻松，脚本会帮你找到调用 foo(parameter1) 的代码，然后替换成 foo(parameter1, NULL)。做完这些后，所有调用这个函数的代码都可以运行一遍，验证下第二个参数为 NULL 是否能正常工作。关于 Coccinelle 的更多信息，以及在不同项目中（当然，也包括
Linux 内核这个项目）的使用方法，请参考项目主页：Cocinelle。

参考文献
本文涵盖了很多方面，这里列出一些参考文档供读者做进一步研究。

KernelHacking
kernel Documentation
Linux Device Drivers, Third Edition
Dynamic Event Tracing in Linux Kernel
Kernel Testing: Tool and Techniques

via:

http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,0

http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,1

http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,2

http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,3

http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,4

http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,5

转载请注明：

转载自X-SLAM

本文链接地址:
Linux 内核的测试和调试