我们在学习操作系统课程的时候,应该都学过fork的概念。fork是一个系统调用,用于将当前进程/线程分裂成完全相同的两个。

在网络上,很多关于fork的文章都大同小异,讲的都是很通用的fork的原理以及大致的过程。但是,大家有没有想过一个问题:用户程序调用fork()和内核下调用fork(),背后的逻辑是不一样的。咱平时如果没有真的去写操作系统的话,应该不会意识到这个问题。

虚拟地址空间分布

首先,我们先来了解一下进程的虚拟地址空间是怎么分布的:

虚拟地址空间的高地址部分为内核空间,低地址部分为用户空间。各个进程之间的内核空间是共享的,只有用户空间才是独占的。

每个进程都有1个内核栈,这个内核栈位于内核空间。并且,每个进程还有一个用户栈,位于低地址部分。

当进程陷入内核态的时候,将会使用内核栈进行处理,当返回用户态的时候,又会换回去,使用用户栈。

需要注意的是,用户栈在用户空间的映射是由操作系统指定的,父子进程的用户栈的虚拟地址是相同的。而父子进程的内核栈的虚拟地址则是不同的。

用户态进程调用fork()

网络上的文章一般描述的是用户态下的fork。用户态的fork是这样的一个过程:

首先,用户进程发起系统调用,陷入内核态。然后在fork系统调用的函数里面,操作系统将会初始化pcb、线程结构体、对用户空间的内存的拷贝,最后把子进程加入调度队列。

这里“内存拷贝”这一点就是关键所在,也是众多文章没有提及的部分。

在用户态的fork中,由于用户进程的栈空间位于就是位于用户空间之中,并且用户栈一般是位于操作系统指定的地址上,不同的进程的用户栈的基地址相同。又由于进程在返回用户态的时候,内核栈是空的,因此,我们只需要将用户空间进行拷贝,当子进程返回用户态的时候,自然就能执行。这是理所当然的事情。

内核态进程的fork

对于在内核态下运行进程而言,其具有在低地址空间的进程的栈,也具有高地址空间部分的内核栈。进程正常运行时,使用其低地址空间部分的栈,发起了系统调用之后,则会使用其高地址空间的内核栈。内核态进程的fork和用户进程的fork是相同的。

内核线程的fork

讲了这么久,这才轮到我们的主角:内核线程。内核线程的fork的过程与前面提到的两者是不同的。

首先,我们需要认识一下内核线程。内核线程是内核中的一些线程,他们共用同一个虚拟地址空间。并且,他们运行时所使用的栈只有内核栈。也就是说,父进程在系统调用返回的时候,并不会执行切换到用户栈的操作(因为根本不存在)!

那么,这样对我们的fork有什么影响呢?

必须拷贝内核栈

由于我们的内核线程只使用内核栈,那就意味着,fork()系统调用到来时,内核栈中除了系统调用的栈帧以外,还会有其他内容!我们必须拷贝内核栈!

如上图所示,如果是用户进程/内核进程的fork,由于其在发起fork()调用之前,他们一直工作在自己的用户空间的栈上,内核栈是空的。发起fork系统调用后,内核栈中才会被压入一个fork调用所在的栈帧。由于进程最终都要返回到其用户栈上,且离开内核的时候,内核栈必须为空。因此我们不需要拷贝内核栈的内容,只需要拷贝用户栈的内容。而用户栈就是位于用户空间内,因此对用户空间的整体拷贝就能完成整个操作。

而内核线程不存在用户栈,其所有运行操作都是在内核栈上进行的,因此在发起fork调用之后,fork调用所在的栈帧不是位于内核栈的底部。由于fork返回后,计算机需要执行内核栈中已有栈帧的内容,因此我们需要拷贝内核栈。

必须重写子进程的栈帧

看了上面之后,可能很多人就会觉得,那不就是直接拷贝内核栈,然后子进程返回的时候直接切换到新的内核栈不就好了吗?这就是一个很大的误区。

如果真的是直接拷贝栈,然后换栈的话,就必然会出错。

再回到文章开头的“虚拟地址空间分布”部分讲的,“父子进程的内核栈的虚拟地址是不同的”。这句话非常重要。内核栈一般是从slab分配器中分配得来的一块内存地址,而且我们也不能仿照对用户进程的操作那样,将每个内核线程的内核栈映射到相同的地址处(这显然是不可行的)。

父子进程的内核栈的虚拟地址的不同,使得我们必须重写栈帧中的内容。这是为什么呢?首先我们需要理解栈帧的结构:

当发生函数调用时,处理器会把当前当前函数的返回地址、栈基址寄存器的值压入栈中。返回地址指的是,被调用的函数返回时,将会从哪个位置开始执行。栈基址寄存器值则指的是当前栈帧的基地址。注意,不是内核栈的基地址,这是很多人的一个误区。

每个栈帧的大小是不相同的,处理器是通过这个值来区分不同的栈帧的。当要弹出一个栈帧时,处理器把这个值赋值给栈指针寄存器,这样就找到了上一个栈帧的起始地址。同样的,上一个栈帧的起始地址部分存的值,就是再上一个栈帧的起始的值。

明白了处理器是如何在栈帧之间跳转之后,我们就能明白为什么必须重写内核栈的栈帧了:直接拷贝内核栈后,新的内核栈中的每个栈帧内的“栈基址寄存器值”的内容仍然是父进程的内核栈的地址。因此我们需要重写这个值,让它指向新的内核栈中的对应地址,这样才是正确的。

重写的方法不难,但是有点绕口:

计算子线程栈帧中某个位置A栈基址寄存器值B相对于父线程的栈底的偏移量delta,然后使用子线程的栈底的地址C减去delta,得到子线程的该栈帧中的栈基址寄存器值D,并将D填写到位置A中。

然后,将D赋值给A,重复上述过程,直到子线程中的所有的栈基址寄存器值被重写。

最后,把子线程的fork()栈帧中的栈指针进行重写,子线程的内核栈就处理完成了。剩余的步骤就和普通的fork没有区别了。

重写的部分,比较拗口,因此在这里放对应的代码,帮助理解:

代码的对应链接在这里:https://github.com/fslongjin/DragonOS/blob/aa7dc4daa5e7f1cc165a9985773e2d2cb23a7281/kernel/process/process.c#L1030


/**
 * @brief 重写内核栈中的rbp地址
 *
 * @param new_regs 子进程的reg
 * @param new_pcb 子进程的pcb
 * @return int
 */
static int process_rewrite_rbp(struct pt_regs *new_regs, struct process_control_block *new_pcb)
{

    uint64_t new_top = ((uint64_t)new_pcb) + STACK_SIZE;
    uint64_t old_top = (uint64_t)(current_pcb) + STACK_SIZE;

    uint64_t *rbp = &new_regs->rbp;
    uint64_t *tmp = rbp;

    // 超出内核栈范围
    if ((uint64_t)*rbp >= old_top || (uint64_t)*rbp < (old_top - STACK_SIZE))
        return 0;

    while (1)
    {
        // 计算delta
        uint64_t delta = old_top - *rbp;
        // 计算新的rbp值
        uint64_t newVal = new_top - delta;

        // 新的值不合法
        if (unlikely((uint64_t)newVal >= new_top || (uint64_t)newVal < (new_top - STACK_SIZE)))
            break;
        // 将新的值写入对应位置
        *rbp = newVal;
        // 跳转栈帧
        rbp = (uint64_t *)*rbp;
    }

    // 设置内核态fork返回到enter_syscall_int()函数内的时候,rsp寄存器的值
    new_regs->rsp = new_top - (old_top - new_regs->rsp);
    return 0;
}

小结

小结一下,内核线程由于其在fork返回之后,仍然使用内核栈,而父子线程的内核栈的地址不同,导致拷贝栈帧后,需要重写子进程内核栈中每个栈帧内保存的栈基址寄存器值,使其能够正常运行。

用户进程/内核进程的fork不需要这样操作的原因则是,他们在fork返回后,内核栈是空的。并且,平时运行的时候,具有独立的用户地址空间,运行时的用户栈都被映射到了相同的虚拟地址处,因此不需要重写也能正常运行。

欢迎加入DragonOS的开发

我发起了DragonOS操作系统项目,目前还处于起步阶段,欢迎感兴趣的朋友们加入!

项目官网:http://DragonOS.org

GitHub地址:https://github.com/fslongjin/DragonOS

开发交流群:115763565

转载请注明来源:https://longjin666.cn/?p=1509

欢迎关注我的公众号“灯珑”,让我们一起了解更多的事物~

你也可能喜欢

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注