Linux进程的数据结构

最新推荐文章于 2024-05-15 12:56:25 发布

PnJg?

最新推荐文章于 2024-05-15 12:56:25 发布

阅读量704

点赞数 2

分类专栏： Linux 文章标签：数据结构 linux

本文链接：https://blog.csdn.net/pnjght/article/details/128254104

版权

Linux 专栏收录该内容

9 篇文章 0 订阅

订阅专栏

在Linux里面，无论是进程还是线程，到了内核里面统一叫任务（task），有一个统一的结构task_struct进行管理。

在程序执行过程中，一旦调用到系统调用，就需要进入内核继续执行，那么讲用户态执行和内核态执行串起来就要用到一下两个重要的成员变量：

struct thread_info thread_info;
void *stack;

用户态函数栈

在用户态中，程序的执行往往是一个函数调用另一个函数。函数调用都是通过栈来进行的。函数调用其实也很简单，其实就是指令跳转，从代码的一个地方跳到另外一个地方。这里比较棘手的问题是，参数和返回地址应该怎么传递过去呢？因为函数调用的特点就是先进后出，先调用的最后返回，跟栈的特点很类似，所以这里用栈保存函数的调用过程很合适。

在进程的内存空间里面，栈是一个从高地址到低地址，往下增长的结构，也就是上面是栈底，下面是栈顶，入栈和出栈的操作都是从下面的栈顶开始的。

先来看32位操作系统的情况。

在CPU里，ESP（Extended Stack Pointer）是栈顶指针寄存器，入栈操作Push和出栈操作Pop指令，会自动调整ESP的值。另外有一个寄存器EBP（Extended Base Pointer），是栈基地址指针寄存器，指向当前栈帧的最底部。

再来看64位操作系统的情况

对于64位操作系统，模式多少有些不一样。因为64位操作系统的寄存器数目比较多。rax用于保存函数调用的返回结果。栈顶指针寄存器变成了rsp，指向栈顶位置。堆栈的Pop和Push操作会自动调整rsp，栈基指针寄存器变成了rbp，指向当前栈帧的起始位置。

以上栈的餐桌都是在进程的内存空间进行的。

内核态函数栈

通过系统调用，从进程的内存空间到内核中了。内核中也有各种各样的函数调用来调用去的，也需要这样一个机制。这时候就用到了一开始提到的成员变量stack，也就是内核栈。

Linux给每个task都分配了内核栈。在32位系统上arch/x86/include/asm/page_32_types.h，是这样定义的：一个PAGE_SIZE是4K，左移一位就是乘以2，也就是8K。

#define THREAD_SIZE_ORDER 1
#define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE_ORDER)

内核栈在64位系统上arch/x86/include/asm/page_64_types.h，是这样定义的：在PAGE_SIZE的基础上左移两位，也即16K，并且要求起始地址必须是8192的整数倍。

#ifdef CONFIG_KASAN
#define KASAN_STACK_ORDER 1
#else
#define KASAN_STACK_ORDER 0
#endif
#define THREAD_SIZE_ORDER (2 + KASAN_STACK_ORDER)
#define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE_ORDER)

内核栈的结构如下：

这段空间的最低位置，是一个thread_info结构。这个结构是对task_struct结构的补充。因为 task_struct结构庞大但是通用，不同的体系结构就需要保存不同的东西，所以往往与体系结构有关的，都放在thread_info里面。

在内核代码里面有这样一个union，将thread_info和stack放在一起，在include/linux/sched.h文件中就有：

union thread_union {
#ifndef CONFIG_THREAD_INFO_IN_TASK
    struct thread_info thread_info;
#endif
    unsigned long stack[THREAD_SIZE/sizeof(long)];
};

在内核栈的最高地址端，存放的是另一个结构pt_regs，定义如下。其中，32位和64位的定义不一样：

#ifdef __i386__
struct pt_regs {
unsigned long bx;
unsigned long cx;
unsigned long dx;
unsigned long si;
unsigned long di;
unsigned long bp;
unsigned long ax;
unsigned long ds;
unsigned long es;
unsigned long fs;
unsigned long gs;
unsigned long orig_ax;
unsigned long ip;
unsigned long cs;
unsigned long flags;
unsigned long sp;
unsigned long ss;
};
#else 
struct pt_regs {
unsigned long r15;
unsigned long r14;
unsigned long r13;
unsigned long r12;
unsigned long bp;
unsigned long bx;
unsigned long r11;
unsigned long r10;
unsigned long r9;
unsigned long r8;
unsigned long ax;
unsigned long cx;
unsigned long dx;
unsigned long si;
unsigned long di;
unsigned long orig_ax;
unsigned long ip;
unsigned long cs;
unsigned long flags;
unsigned long sp;
unsigned long ss;
/* top of stack page */
};
#endif

当系统调用从用户态到内核态的时候，首先要做的第一件事情，就是将用户态运行过程中的CPU上下文保存起来，其实主要就是保存在这个结构的寄存器变量里。这样当从内核系统调用返回的时候，才能让进程在刚才的地方接着运行下去。

通过task_struct找内核栈

如果有一个task_struct的stack指针在手，可以通过下面的函数找到这个线程内核栈：

static inline void *task_stack_page(const struct task_struct *task)
{
    return task->stack;
}

从task_struct如何得到相应的pt_regs呢？我们可以通过下面的函数：

/*
 * TOP_OF_KERNEL_STACK_PADDING reserves 8 bytes on top of the ring0 stack.
 * This is necessary to guarantee that the entire "struct pt_regs"
 * is accessible even if the CPU haven't stored the SS/ESP registers
 * on the stack (interrupt gate does not save these registers
 * when switching to the same priv ring).
 * Therefore beware: accessing the ss/esp fields of the
 * "struct pt_regs" is possible, but they may contain the
 * completely wrong values.
 */
#define task_pt_regs(task) \
({                                                             \
    unsigned long __ptr = (unsigned long)task_stack_page(task); \
    __ptr += THREAD_SIZE - TOP_OF_KERNEL_STACK_PADDING;         \
    ((struct pt_regs *)__ptr) - 1;                              \
})

这是先从task_struct找到内核栈的开始位置。然后这个位置加上THREAD_SIZE就到了最后的位置，然后转换为struct pt_regs，再减一，就相当于减少了一个pt_regs的位置，就到了这个结构的首地址。

这里面有一个TOP_OF_KERNEL_STACK_PADDING，这个的定义如下：

#ifdef CONFIG_X86_32
# ifdef CONFIG_VM86
# define TOP_OF_KERNEL_STACK_PADDING 16
# else
# define TOP_OF_KERNEL_STACK_PADDING 8
# endif
#else
# define TOP_OF_KERNEL_STACK_PADDING 0
#endif

也就是说，32位机器上是8，其他是0。这是为什么呢？因为压栈pt_regs有两种情况。我们知道，CPU用ring来区分权限，从而Linux可以区分内核态和用户态。

因此，第一种情况，我们拿涉及从用户态到内核态的变化的系统调用来说。因为涉及权限的改变，会压栈保存SS、ESP寄存器的，这两个寄存器共占用8个byte。

另一种情况是，不涉及权限的变化，就不会压栈这8个byte。这样就会使得两种情况不兼容。如果没有压栈还访问，就会报错，所以还不如预留在这里，保证安全。在64位上，修改了这个问题，变成了定长的。

支持，如果能拿到task_struct，那么就能轻松得到内核栈和内核寄存器。

通过内核栈找到task_struct

那如果一个当前在某个CPU上执行的进程，想知道自己的task_struct在哪里，又该怎么办呢？

这就要通过我们的thread_info这个结构了：

struct thread_info {
    struct task_struct *task; /* main task structure */
    __u32 flags; /* low level flags */
    __u32 status; /* thread synchronous flags */
    __u32 cpu; /* current CPU */
    mm_segment_t addr_limit;
    unsigned int sig_on_uaccess_error:1;
    unsigned int uaccess_err:1; /* uaccess failed */
};

这里面有个成员变量task指向task_struct，所以我们常用current_thread_info()->task来获取 task_struct：

static inline struct thread_info *current_thread_info(void)
{
    return (struct thread_info *)(current_top_of_stack() - THREAD_SIZE);
}

而thread_info的位置就是内核栈的最高位置，减去THREAD_SIZE，就到了thread_info的起始地址。

但是现在变成这样了，只剩下一个flags：

struct thread_info {
     unsigned long flags; /* low level flags */
};

这时候怎么获取当前运行中的task_struct呢？current_thread_info有了新的实现方式。在include/linux/thread_info.h中定义了current_thread_info：

#include <asm/current.h>
#define current_thread_info() ((struct thread_info *)current)
#endif

那current又是什么呢？在arch/x86/include/asm/current.h中定义了：

struct task_struct;
DECLARE_PER_CPU(struct task_struct *, current_task);
static __always_inline struct task_struct *get_current(void)
{
    return this_cpu_read_stable(current_task);
}
#define current get_current

新的机制里面，每个CPU运行的task_struct不通过thread_info获取了，而是直接放在Per CPU 变量里面了。

多核情况下，CPU是同时运行的，但是它们共同使用其他的硬件资源的时候，我们需要解决多个 CPU之间的同步问题。

Per CPU变量是内核中一种重要的同步机制。顾名思义，Per CPU变量就是为每个CPU构造一个变量的副本，这样多个CPU各自操作自己的副本，互不干涉。比如，当前进程的变量 current_task就被声明为Per CPU变量。

要使用Per CPU变量，首先要声明这个变量，在arch/x86/include/asm/current.h中有：

DECLARE_PER_CPU(struct task_struct *, current_task);

然后是定义这个变量，在arch/x86/kernel/cpu/common.c中有：

DEFINE_PER_CPU(struct task_struct *, current_task) = &init_task;

也就是说，系统刚刚初始化的时候，current_task都指向init_task。

当某个CPU上的进程进行切换的时候，current_task被修改为将要切换到的目标进程。例如，进程切换函数__switch_to就会改变current_task：

__visible __notrace_funcgraph struct task_struct *
__switch_to(struct task_struct *prev_p, struct task_struct *next_p)
{
......
    this_cpu_write(current_task, next_p);
......
    return prev_p;
}

当要获取当前的运行中的task_struct的时候，就需要调用this_cpu_read_stable进行读取。

现在如果你是一个进程，正在某个CPU上运行，就能够轻松得到task_struct了。

总结：

在用户态，应用程序进行了至少一次函数调用。32位和64的传递参数的方式稍有不同，32位的就是用函数栈，64位的前6个参数用寄存器，其他的用函数栈。

在内核态，32位和64位都使用内核栈，格式也稍有不同，主要集中在pt_regs结构上。

在内核态，32位和64位的内核栈和task_struct的关联关系不同。32位主要靠thread_info， 64位主要靠Per-CPU变量。

PnJg?

关注

2
点赞
踩
4

收藏

觉得还不错? 一键收藏
0
评论
Linux进程的数据结构

在用户态，应用程序进行了至少一次函数调用。32位和64的传递参数的方式稍有不同，32位的就是用函数栈，64位的前6个参数用寄存器，其他的用函数栈。在内核态，32位和64位都使用内核栈，格式也稍有不同，主要集中在pt_regs结构上。在内核态，32位和64位的内核栈和task_struct的关联关系不同。32位主要靠thread_info， 64位主要靠Per-CPU变量。
复制链接

扫一扫