Linux Subreaper 机制及内核态逃离方法(PR_SET_CHILD_SUBREAPER, prctl, systemed)

PS：要转载请注明出处，本人版权所有。

PS: 这个只是基于《我自己》的理解，

如果和你的原则及想法相冲突，请谅解，勿喷。

环境说明

  无

前言

  由于某些其他的原因，我们在测试另外一个问题的时候发现了一个奇怪的现象：在我们一直朴素的认知下，如果一个程序创建了parent-process和child-process，这个时候，当child-process正在运行，parent-process退出的时候，child-process会被托孤到init进程。但是我们却通过pstree -p 发现了并不是这样的，他会被托孤到某一个特殊进程下面，这个特殊进程并不是init进程，而是init进程下面的某一个进程。下面是这个现象的验证过程：

  测试程序

#include<unistd.h>
#include<sys/types.h>
#include<stdio.h>

intmain(int argc, char * argv[])
{
int pid = fork();

if (pid < 0)
printf("fork failed.\n");

elseif (pid > 0){

printf("parent : child pid = %d\n", pid);
    }
else{

printf("child doing ... ...\n");
printf("first get ppid = %d\n", getppid());
        sleep(20);
printf("second get ppid = %d\n", getppid());
        sleep(1000);
    }
    sleep(15);
return0;
}

  我们运行这个程序后，其运行输出如下图：

  我们对这个图进行分析，可以知道，当前的运行a.out进程pid是72140，然后子进程的pid是72141，在parent-process退出后，我们再次获取ppid，可以看到输出是3203。

  接着我们看一下在parent-process未退出时的进程树图片节选：

  在图中我们可以知道，我们的a.out在systemd(3203)->gnome-terminal-(3741)->bash(5073)->a.out(72140)

  接着我们看一下在parent-process退出时的进程树图片节选：

  在图中我们可以知道，当parent-process退出后，子进程72141被托孤给了systemd(3203)，并不是我们熟知的pid为1的init进程。这里提前透露一下3203是systemd --user一个进程（同时也是一个subreaper）。

  带着对这个问题的疑问，我查询了相关的资料，做了相关的实验，查询到这个现象的原因是PR_SET_CHILD_SUBREAPER相关导致的，因此有了本文的相关内容。

什么是Subreaper(PR_SET_CHILD_SUBREAPER) ？

  对于这个问题，我们还是要去看man手册，链接如下：https://man7.org/linux/man-pages/man2/prctl.2.html

  通过prctl函数，我们可以对当前进程做很多有趣的设置，其中一个就是PR_SET_CHILD_SUBREAPER选项，他主要是用来收集这些托孤进程的，一般是用来给一些守护进程管理进程（例如：上文提到的systemd）使用，使得一个进程能够管理自己的所有后代进程。其主要还是操作当前进程的task_struct中的is_child_subreaper属性，下面是实现的源码节选：

//kernel/sys.c
staticintpropagate_has_child_subreaper(struct task_struct *p, void *data)
{
/*
     * If task has has_child_subreaper - all its descendants
     * already have these flag too and new descendants will
     * inherit it on fork, skip them.
     *
     * If we've found child_reaper - skip descendants in
     * it's subtree as they will never get out pidns.
     */
if (p->signal->has_child_subreaper ||
        is_child_reaper(task_pid(p)))
return0;

    p->signal->has_child_subreaper = 1;
return1;
}

//kernel/sys.c
SYSCALL_DEFINE5(prctl, int, option, unsignedlong, arg2, unsignedlong, arg3,
unsignedlong, arg4, unsignedlong, arg5)
{
structtask_struct *me = current;
//...
switch (option){
//...
case PR_SET_CHILD_SUBREAPER:
            me->signal->is_child_subreaper = !!arg2;
if (!arg2)
break;
//此函数遍历当前进程的所有子进程，并调用propagate_has_child_subreaper设置has_child_subreaper属性。
            walk_process_tree(me, propagate_has_child_subreaper, NULL);
break;
case PR_GET_CHILD_SUBREAPER:
            error = put_user(me->signal->is_child_subreaper,
                    (int __user *)arg2);
break;
//...
    }
//...
}

  通过如上的源码，我们可以知道了PR_SET_CHILD_SUBREAPER的实现部分原理，但是现在我们还是不知道为啥这样设置之后，当一个进程还有子进程时，当前进程退出后，子进程就托孤给了这个子进程收割者。这里可以提前透露一下，主要是和task_struct中的has_child_subreaper属性有关系。

当含有子进程的父进程退出时，怎么进行托孤的？

  其实从问题就可以看出一点端倪，这个托孤的动作一般是发生在进程退出的时候，所以我们去找进程退出相关的代码应该能够找到一些启发。一般来说，我们的进程退出都会调用exit系统调用，对应到内核态，其实就是do_exit。我们通过has_child_subreaper来全局搜索，可以看到一些关联。下面是部分代码节选：

void __noreturn do_exit(long code)
{
structtask_struct *tsk = current;
int group_dead;

//...
    exit_notify(tsk, group_dead);
//...
}

/*
 * Send signals to all our closest relatives so that they know
 * to properly mourn us..
 */
staticvoidexit_notify(struct task_struct *tsk, int group_dead)
{
//...
    LIST_HEAD(dead);

//...
    forget_original_parent(tsk, &dead);
//...
}

/*
 * This does two things:
 *
 * A.  Make init inherit all the child processes
 * B.  Check to see if any process groups have become orphaned
 *    as a result of our exiting, and if they have any stopped
 *    jobs, send them a SIGHUP and then a SIGCONT.  (POSIX 3.2.2.2)
 */
staticvoidforget_original_parent(struct task_struct *father,
struct list_head *dead)
{
structtask_struct *p, *t, *reaper;

if (unlikely(!list_empty(&father->ptraced)))
        exit_ptrace(father, dead);

/* Can drop and reacquire tasklist_lock */
//通过task_active_pid_ns()->child_reaper查找到一个reaper,然后返回出来，注意一般情况下这里查出来的进程就是当前namespace的init进程。
    reaper = find_child_reaper(father, dead);
if (list_empty(&father->children))
return;

//根据init进程和has_child_subreaper属性，查询真正符合条件的reaper
    reaper = find_new_reaper(father, reaper);
    list_for_each_entry(p, &father->children, sibling) {//遍历当前退出进程的所有子进程
        for_each_thread(p, t) {//遍历所有子进程的线程
            RCU_INIT_POINTER(t->real_parent, reaper);//设置真正的父进程，这里的父进程就是上面我们查找出来了的满足要求的reaper
            BUG_ON((!t->ptrace) != (rcu_access_pointer(t->parent) == father));
if (likely(!t->ptrace))
                t->parent = t->real_parent;
if (t->pdeath_signal)
                group_send_sig_info(t->pdeath_signal,
                            SEND_SIG_NOINFO, t,
                            PIDTYPE_TGID);
        }
/*
         * If this is a threaded reparent there is no need to
         * notify anyone anything has happened.
         */
if (!same_thread_group(reaper, father))
            reparent_leader(father, p, dead);
    }
    list_splice_tail_init(&father->children, &reaper->children);
}

  在forget_original_parent中，我们可以看到整个方法的作用就是，找到一个reaper，然后将所有子进程交付给这个reaper。

我们怎么逃离PR_SET_CHILD_SUBREAPER的影响呢？

  其实这个问题就在forget_original_parent中的find_new_reaper函数中，也就是has_child_subreaper这个属性怎么生效，下面我们来看看这个函数的功能：

/*
 * When we die, we re-parent all our children, and try to:
 * 1. give them to another thread in our thread group, if such a member exists
 * 2. give it to the first ancestor process which prctl'd itself as a
 *    child_subreaper for its children (like a service manager)
 * 3. give it to the init process (PID 1) in our pid namespace
 */
staticstruct task_struct *find_new_reaper(struct task_struct *father,
struct task_struct *child_reaper)
{
structtask_struct *thread, *reaper;

    thread = find_alive_thread(father);
if (thread)
return thread;

if (father->signal->has_child_subreaper) {//注意has_child_subreaper属性生效的地方。
unsignedint ns_level = task_pid(father)->level;
/*
         * Find the first ->is_child_subreaper ancestor in our pid_ns.
         * We can't check reaper != child_reaper to ensure we do not
         * cross the namespaces, the exiting parent could be injected
         * by setns() + fork().
         * We check pid->level, this is slightly more efficient than
         * task_active_pid_ns(reaper) != task_active_pid_ns(father).
         */
for (reaper = father->real_parent;
             task_pid(reaper)->level == ns_level;
             reaper = reaper->real_parent) {
if (reaper == &init_task)
break;
if (!reaper->signal->is_child_subreaper)
continue;
            thread = find_alive_thread(reaper);
if (thread)
return thread;
        }
    }

return child_reaper;
}

  我们从find_new_reaper中可以知道，当has_child_subreaper有值时，我们就从当前进程的父进程开始查找，当找到一个进程的is_child_subreaper属性是有值时，我们就返回这个进程作为真正的reaper。当has_child_subreaper无值时，就是以init进程为reaper来托孤。

  从以上的推理来看，我们有两个方案可以逃离PR_SET_CHILD_SUBREAPER影响：

• • 直接改写真正PR_SET_CHILD_SUBREAPER的地方，不启用这个属性。例如修改systemd的源码。
• • 写一个内核态的小工具，修改指定进程的as_child_subreaper的值，当我们禁用此值时，在进程退出时，就会把子进程托孤给init进程。

我们怎么逃离PR_SET_CHILD_SUBREAPER的影响呢？

  按照上一个小结的结论，我们一般情况下是不会去改一些开源的系统程序，例如：systemd。因此我们选择直接写一个基本的内核态模块，直接修改其task_struct数据结构即可。ko文件如下：

#include<linux/module.h>/* Needed by all modules */
#include<linux/kernel.h>/* Needed for KERN_INFO */

#include<linux/pid.h>
#include<linux/sched.h>
#include<linux/sched/signal.h>
#include<linux/sched/mm.h>
#include<linux/mm_types.h>
#include<linux/rwsem.h>
#include<linux/slab.h>
#include<linux/fs.h>
#include<linux/mmap_lock.h>
#include<linux/pid_namespace.h>

MODULE_AUTHOR("sky <sky@sky.com>");
MODULE_DESCRIPTION("sky's hack");
MODULE_LICENSE("GPL");
MODULE_VERSION("1.0.0");

staticint hack_pid = -1;

module_param_named(hack_pid, hack_pid, uint, S_IRUGO);
MODULE_PARM_DESC(hack_pid, "hack_pid");


intinit_module(void)
{
    printk(KERN_INFO "Hello sky_hack.\n");
    printk(KERN_INFO "hack pid %d\n", hack_pid);

    rcu_read_lock();

structpid * _pid_struct = find_vpid(hack_pid);
if (NULL == _pid_struct){

        printk("get pid struct failed.\n");
        rcu_read_unlock();
return-1;
    }

structtask_struct * _task_struct = get_pid_task(_pid_struct, PIDTYPE_PID);
if (NULL == _task_struct){

        printk("get task struct failed.\n");
        rcu_read_unlock();
return-1;
    }


structmm_struct * _mm_struct = get_task_mm(_task_struct);
if (NULL == _mm_struct){

        printk("get mm struct failed.\n");
        rcu_read_unlock();
return-1;
    }

    mmap_read_lock(_mm_struct);
if (_mm_struct->exe_file) {

char * pathname = kmalloc(PATH_MAX, GFP_ATOMIC);
if (pathname) {
char * p = d_path(&_mm_struct->exe_file->f_path, pathname, PATH_MAX);
/*Now you have the path name of exe in p*/
                    printk(KERN_INFO "process full path %s\n", p);
                }
                kfree(pathname);
    }
    mmap_read_unlock(_mm_struct);

structpid_namespace *pid_ns = task_active_pid_ns(_task_struct);
structtask_struct *reaper = pid_ns->child_reaper;

    printk(KERN_INFO "pid_ns->child_reaper=%x, current task_struct=%x\n", pid_ns->child_reaper, _task_struct);
    printk(KERN_INFO "is_child_subreaper %d\n", _task_struct->signal->is_child_subreaper);
    printk(KERN_INFO "has_child_subreaper %d\n", _task_struct->signal->has_child_subreaper);

//escape from a subreaper by do_exit()
    _task_struct->signal->has_child_subreaper = 0;
    rcu_read_unlock();

return0;
}

voidcleanup_module(void)
{
    printk(KERN_INFO "Goodbye sky_hack.\n");
}

  当前这个驱动的唯一目的就是把指定pid进程的has_child_subreaper改为0，这样就可以逃离subreaper。

  编译Makefile

obj-m += sky_hack.o
all:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

  下面我们再一次做上面的测试，运行a.out，查看a.out相关的进程树，然后运行sky_hack.ko hack_pid=‘a.out进程id’，等待一段时间后，当a.out退出后，再次查看a.out的相关进程树即可。

  运行a.out的输出：

  我们其实可以看到，按照上面我们的说明进行操作后，a.out第二次打印的ppid已经是1了，这意味着我们逃离subreaper成功了。

  下面我们看看insmod sky_hack.ko hack_pid=14749的输出：

  我们其实可以看到，在驱动里面我们打印了a.out进程的has_child_subreaper属性是1，因此我们在驱动中重置了它，导致了退出时，成功托孤给了init进程。

  下面我们看看这整个阶段中的进程树状况：

  这里的进程分布和上述开始的一样。

  我们看看逃离subreaper后：

  这里的进程分布就和最开始的不一样的，我们成功的将我们的子进程托孤给了init进程。

后记

  我们首先从一个其他问题，遇到了这个现象，然后我们深究了这个现象产生的原因，并且最终尝试设计出逃离这种现象的技术方案。这其中会涉及一些内核源码，驱动编写，同时加深了我们对subreaper的理解。经过这些过程后，我们对Linux内核，Linux的应用开发会有一个新的认知和理解。同时也增强了我们解决问题的综合能力。

参考文献

• • 无

PS: 请尊重原创，不喜勿喷。

PS: 要转载请注明出处，本人版权所有。

PS: 有问题请留言，看到后我会第一时间回复。