测试结果如下所示：

　　从蓝色的部分可以看出，current->blocked为0，也是说当前内核线程的信号掩码为0，所以在do_sigpending()中调用sigandsets()来将当前进程的的信号位图和掩码执行与操作的结果总是0。

　　从测试结果来看调用sys_sigpending()来获取内核线程的方法不行，获取内核线程接收的信号可以通过将current->pending.signal和current->signal->shared_pending.signal中的信号合并得到。至此，我们解决了第一个问题，如何获取内核线程接收到的信号。

　　接下来解决另一个问题，是要获取系统重启时内核线程接收到的信号。reboot之后系统会重启，重启之后模块中输出的信息没有保存在系统日志/var/log/messages中，需要想别的办法来拿到重启时模块输出的日志信息。google了一番没有什么收获，后想到使用kdump+crash来拿到重启时系统日志信息。kdump可以在内核崩溃时转储生成core文件，crash用来分析生成的core文件，在crash中使用dmesg命令可以看到系统崩溃时的日志信息。所以如果在我们的内核线程接收到信号，打印完日志信息后让内核崩溃可以看到我们输出的日志信息了。让内核崩溃很简单，使用BUG（）宏或直接调用panic（）函数。修改测试thread_process()函数，将if分支中的”break;“语句替换为BUG()或panic()，代码没必要贴了，直接上测试结果：

　　上图中蓝色圈住的部分，可以可以看到同时接收到了SIGTERM和SIGCONT信号，但是这个测试结果是在家里用虚拟机测试的，在公司中拿真实的服务器（刀片机）测试时只检测到SIGTERM信号。本来想做一个处理，让测试结果看起来和真实的服务器一致，但是想通过这个细节给没有被虚拟机坑过的人一个提醒，真正测试开发的程序时一定要使用和生产相同的环境，尽量不用使用虚拟机来测试。曾经测试一个网络相关的模块时，和同事花了整整一上午，后确认是虚拟机提供的虚拟网卡驱动的问题，真心坑啊！

　　除了测试系统重启时内核线程接收的信号，还测试了关机时内核线程接收的信号，发现关机时内核线程接收到的信号是竟然是SIGCONT，而不是认为的SIGKILL或SIGSTOP！以后遇到不确定的问题，一定要自己动手测试一番，以免出错。

　　可能有人会问，为什么不直接看sys_reboot()系统调用来看会给内核线程发送什么信号？而要这么麻烦来测试？在测试之前，看了sys_reboot()的源码，但是找了半天也没找到在什么地方发送的信号，后放弃了，因为现在感觉没有必要花太多的的时间来研究系统重启或关机时内核的处理。内核现在太庞大了，如果各个方面都研究的话不太现实，也没有什么意义，暂时以现在用到的部分为主，等有时间再细细研究其他感兴趣的地方。