内核情景分析：强制杀死一个进程的执行过程

最新推荐文章于 2023-07-17 10:22:33 发布

longyu_wlz

最新推荐文章于 2023-07-17 10:22:33 发布

阅读量3.2k

点赞数

分类专栏： LINUNX KERNEL 文章标签： kill -9 进程死亡 do_exit

本文链接：https://blog.csdn.net/Longyu_wlz/article/details/108990092

版权

LINUNX KERNEL 专栏收录该内容

42 篇文章

订阅专栏

前言

我们常常需要强制杀死一个进程，这种情况不同于正常退出的方式，一些退出流程将不会被执行。

按照正常的逻辑，这样的行为应该会导致一些资源没有得到释放，可是实际操作中多次强制杀死进程也没有出现啥异常现象。

那么问题来了： kill -9 杀死进程在内核中到底有怎样的处理过程呢？本文中，我将逐步的揭开这个问题的谜团。

信号的基础工作原理

信号模拟了硬件中断的处理流程。cpu 在每条指令执行完成后检测中断引脚，判断是否有中断到来，检测到有中断发生后打断当前执行的任务并保存现场然后跳转到中断服务程序开始运行。

信号与硬件中断的处理过程有类似之处，却也有显著的区别，它的主要步骤如下：

向某个进程发送信号事件，信号事件对应的结构被挂入到目标进程的 sigpending 链表中，并置位信号状态掩码中对应的位
目标进程在从内核态返回用户态的过程中检测是否有挂起的信号，发现有挂起的信号则从链表中每次拿出一个信号事件进行处理直到链表为空
获取到一个信号事件后，根据信号类型分发到不同的逻辑中，主要有一下三种大类
- 对于设定为 SIG_IGN 状态的信号直接忽略
- 对于有通过 signal、sigaction 注册信号处理函数的信号，设定堆栈后跳转到用户态的信号处理函数开始执行
- 对于设定为 SIG_DFL、其它类型的信号执行杀死进程的操作
对于有注册信号处理函数的信号，内核在设定好堆栈后返回到用户态后直接从用户态信号处理函数开始执行，此函数返回后触发一个 sigreturn 系统调用后再次回到内核，然后恢复旧的堆栈继续运行

对于 SIGKILL、SIGSTOP 这两种不可被用户程序捕获的信号以及设定了 SIG_IGN、SIG_DEF 行为的信号而言，这些信号的处理过程均在内核态完成。

由于信号处理函数是在用户态程序的代码段中，当用户注册了一个非默认值的可捕获信号信号处理函数时，才会进入用户态执行，这里的过程实际上涉及一些相对复杂的架构依赖性操作，与这里要探讨的问题关系不大，不展开描述了。

信号在何时被处理

信号不同于硬件中断，它是软件上的行为，不能做到在每条指令执行完成后都进行检测并响应。一般来说，它只在内核态返回用户态的过程中被检测并处理，主要有如下两种情况：

当前进程由于系统调用、中断、异常而进入系统空间后，从系统空间返回用户空间的前夕
当前进程在内核中进入睡眠以后刚被唤醒的时候，由于信号的存在而提前返回到用户空间

kill -9 信号的处理过程

kill -9 表示发送 SIGKILL 信号，这个信号是不能被用户程序捕获的，它的处理过程完全在内核态完成，核心过程在于调用 do_group_exit 来执行所谓的“组退出”过程杀死整个线程组。

do_group_exit 函数会杀死 current 线程组中的其他进程（如果存在的话），它会向所有不同于 current 的同一个 tgid 中的其它进程发送 SIGKILL 信号，这些进程最终都将调用 do_exit 函数，从而终止运行。

do_exit 是一个相当复杂的函数，它的主要目的是回收进程使用的资源，这也是我们调用了 kill -9 没有出问题的根本原因——内核替我们完成了这些必要的回收工作。

在进一步描述前，先回忆回忆之前研究过的实时操作系统中任务退出函数的执行过程与原理。

实时操作系统中的任务退出函数

我在 rt-thread 与 ucos 中任务退出时如何调用退出函数这篇博客中描述了实时操作系统中任务退出函数调用的过程，它其实是在每个任务的栈中预先设定了一个调用栈，将此栈的返回地址设置为进程退出的函数，这样当进程主函数执行完成后，弹栈过程会将预设的返回地址赋值给 pc 从而执行退出函数。

rt-thread 实时操作系统中也有类似 linux 中延后释放 tcb 的过程，它实际是在 idle 任务中来回收进程的 tcb 的。

对于实时操作系统来说，它占用的资源并不像 linux 系统那样多，其中最重要的应当是 ipc 资源了，对这些资源的回收也是其中的主要逻辑。

任务退出函数的复杂性

任务退出函数在某种意义上要比任务创建函数更为复杂。例如对于 ipc 来说，如果有其它进程在等待当前进程占用的 ipc 资源而睡眠，当前任务退出的时候必须考虑到这种情况，必须唤醒相关的进程。

试想如果它不做任何操作就悄无声息的死亡了，占用的 ipc 资源没有被回收，那么这些等待这些 ipc 资源的进程将一直睡眠，这是我们不愿意看到的结果。

再次回到 do_exit

进程在退出系统之前要释放所有的资源，在任务创建过程中从父进程继承的资源有存储空间、打开文件、工作目录、信号处理表等等，相应的在 do_exit 中就有 __exit_mm()、__exit_files()、__exit_sighand。

对于其它非继承的资源如信号量等也需要进行释放。这里有这样一个准则：在 task_struct 结构体中，只要是一个指针，在进程创建时以及运行过程中要为其在内核中分配一个数据结构或缓冲区，而且这个指针又是通向这个数据结构或缓冲区的唯一途径，那就一定要把它释放掉，不然就会造成内核的存储空间泄露。（摘自《Linux 内核源代码情景分析》）

正是因为内核在 do_exit 中针对用户态程序使用的不同资源进行了回收，这才让 kill -9 这样的方式不至于导致存储空间泄露。

malloc 与 free 对应堆空间的回收

我们可以想想在使用 c 语言编写用户态程序时中一般要求 malloc 与 free 成对存在，如果只调用了 malloc 而不调用 free，则会产生存储空间的泄露，这里的泄露实际上针对的是持续运行过程的说法。

malloc 申请的动态内存空间会被映射到程序虚拟内存的堆中，堆也只是程序虚拟内存中的页面，与其它存储区域一样都是通过底层的 mmap 映射到虚拟内存中的，通过执行 pmap、查看 /proc/pid/maps 可以看到。这些页面在 __exit_mm 函数中最终调用到的 exit_mmap 中被释放。