Linux内核中使用 task_struct 结构来表示一个进程，这个结构体保存了进程的所有信息，所以它非常庞大，在讲解Linux内核的进程管理，我们有必要先分析这个 task_struct 中的各项成员
双向链表：
struct list_head tasks;
Linux将所有的 task_struct 串联成一个双向循环链表
1、任务ID：
pid_t pid;
pid_t tgid;
struct task_struct *group_leader;
- pid：每个进程都有自己的 pid，它在内核中是唯一的，在Linux中，我们可以使用 ps -ef查看所有的进程，其中 PID 就是进程号。pid可以给用户查看指定进程的信息，可以通过pid给指定的进程发送信号
- 是线程组的意思，所谓的线程组是什么意思呢？内核中不管是线程或者是进程都是使用 task_struct 来表示，一个进程也可以称为主线程，由它创建多个线程，这些线程和进程的主线程就称为一个线程组。每个线程都有自己的pid，而 tgid 则等于进程的主线程的 pid，这样也就可以区分谁是主线程，谁是被主线程创建出来的
- group_leader：指向线程组主线程的进程描述符通过 getpid 返回的是 tgid，也就是说同一个线程组共享一个 pid
2、信号处理:
/* Signal handlers: */
struct signal_struct *signal;
struct sighand_struct *sighand;
sigset_t blocked;
sigset_t real_blocked;
sigset_t saved_sigmask;
struct sigpending pending;
unsigned long sas_ss_sp;
size_t sas_ss_size;
unsigned int sas_ss_flags;
- blocked：sigset_t 是一个位图，每个位都表示一个信号。blocked 表示的是该进程的哪些信号被阻塞暂不处理
- pending：表示进程接收到了哪些信号，需要被处理
- sighand：用户可以定义相应信号的处理方法，其信息保存在这里
- sas_ss_xxx：信号的处理默认使用的是进程用户空间的函数栈，也可以开辟新的栈专门用于信号处理，这三个变量就是用户维护这个栈信息
在 signal 中，定义了 struct sigpending shared_pending，这个 shared_pending 和 pending 的区别是，pending 表示该 task_struct 收到的信号，而 shared_pending 是整个线程组共享的。也就是说，对于 pending 中接收到的信号，只能由这个 task_struct 来处理，而 shared_pending 中收到的信号，可以由线程组中的任意一个线程处理
进程状态:
在 task_struct 中，定义了这样几个变量，与进程的状态有关:
volatile long state; /* -1 unrunnable, 0 runnable, >0 stopped */
int exit_state;
unsigned int flags;
state 和 exit_state 的定义如下：
/* Used in tsk->state: */
#define TASK_RUNNING 0
#define TASK_INTERRUPTIBLE 1
#define TASK_UNINTERRUPTIBLE 2
#define __TASK_STOPPED 4
#define __TASK_TRACED 8
/* Used in tsk->exit_state: */
#define EXIT_DEAD 16
#define EXIT_ZOMBIE 32
#define EXIT_TRACE (EXIT_ZOMBIE | EXIT_DEAD)
state相关：
- TASK_RUNNING：运行态或就绪态，表示进程正在运行，或者进程处于就绪态位于运行队列中
- TASK_INTERRUPTIBLE：可中断的睡眠态，表示进程正在睡眠等待，睡眠过程中可以被信号唤醒
- TASK_UNINTERRUPTIBLE：不可中断的睡眠态，表示进程正在睡眠等待，并且睡眠过程中不可被信号唤醒。这就意味着，如果有一个进程一直处于这种状态，我们无法使用信号将其杀死，唯一的办法就是重启，所以这个状态较少使用
- __TASK_STOPPED：在进程收到 SIGSTOP、SIGTTIN、SIGTSTP 或者 SIGTTO 等信号的时候，进入该状态
- __TASK_TRACED：进程被另一个进程跟踪的时候，进入此状态
exit_state相关：
- EXIT_ZOMBIE：僵尸态，如果一个进程已经死亡，但在内核中的 task_struct 还未被父进程回收，那么进程就会变成僵尸进程
- EXIT_DEAD：最终态，进程的资源被父进程回收后，会从 EXIT_ZOMBIE 变成 EXIT_DEAD
进程的状态转换如下：
flags的某些定义如下：
#define PF_EXITING 0x00000004
#define PF_VCPU 0x00000010
#define PF_FORKNOEXEC 0x00000040- PF_EXITING：表示正在退出
- PF_VCPU：表示运行在虚拟CPU上
- PF_FORKNOEXEC：表示 fork 完，还没有调用 exec
进程调度:
进程调度相关的变量如下:
//是否在运行队列上
int on_rq;
//优先级
int prio;
int static_prio;
int normal_prio;
unsigned int rt_priority;
//调度器类
const struct sched_class *sched_class;
//调度实体
struct sched_entity se;
struct sched_rt_entity rt;
struct sched_dl_entity dl;
//调度策略
unsigned int policy;
//可以使用哪些CPU
int nr_cpus_allowed;
cpumask_t cpus_allowed;
struct sched_info sched_info;
- on_rq：表明进程是否在运行队列上
- prio、static_prio、normal_prio、rt_priority：优先级相关的变量
- sched_class：调度类，也就是这个进程采用的调度策略
- se、rt、dl：调度实体，调度类操作的单位
- policy：调度策略，与 sched_class 对应
- nr_cpus_allowed、cpus_allowed：表明进程可以在哪些CPU上运行
运行统计信息:
u64 utime;//用户态消耗的CPU时间
u64 stime;//内核态消耗的CPU时间
unsigned long nvcsw;//自愿(voluntary)上下文切换计数
unsigned long nivcsw;//非自愿(involuntary)上下文切换计数
u64 start_time;//进程启动时间，不包含睡眠时间
u64 real_start_time;//进程启动时间，包含睡眠时间
进程亲缘关系:
struct task_struct __rcu *real_parent; /* real parent process */
struct task_struct __rcu *parent; /* recipient of SIGCHLD, wait4() reports */
struct list_head children; /* list of my children */
struct list_head sibling; /* linkage in my parent's children list */
进程之间有亲缘关系，所以所有的进程实际上是一棵树，上面说过，进程组成一个双向循环链表，这并不冲突，因为既是双向循环链表，又是一棵树:
- parent：指向父进程
- children：所有子进程的组成的链表的链表头
- sibling：兄弟链表，又相当于父进程的 children 链表中的一个节点
所有进程组成的关系如下:
real_parent 和 parent 在大多数情况下是一样的，只有在某些特殊情况下才会不一样
内存管理:
struct mm_struct *mm;
struct mm_struct *active_mm;
每个进程都有自己独立的地址空间，内核使用了 mm_struct 结构体来管理进程的地址空间
文件与文件系统:
/* Filesystem information: */
struct fs_struct *fs;
/* Open file information: */
struct files_struct *files;
每个进程都有一个文件系统的数据结构，就是 fs_struct
每个进程还要维护它所打开的文件，这些信息在 files_struct 中
进程内核栈:
1、栈结构：
上面讲解了 task_struct 的大部分成员，下面来讲解进程的内核栈
程序的运行需要使用到栈，所以不管进程是在内核态运行还是在用户态运行都需要用到栈
Linux将进程地址空间分为内核空间和用户空间，它们之间是不能直接访问的，而一个进程某些时候可能在用户态运行，某些时候可能在内核态运行（发生系统调用时），所以一个进程既需要用户栈又需要内核栈
下面就来讲解内核给进程分配的栈结构
在 task_struct 中，有一个变量指向该进程的内核栈，如下：
struct task_struct {
...
void *stack;
...
};
内核栈的大小在内核中的定义如下：
#define THREAD_SIZE_ORDER 1
#define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE_ORDER)
一个 PAGE_SIZE 是4K，左移一位就是乘以2，所以 THREAD_SIZE 就是8K，所以大体j结构如下：
接下来我们看这8K的空间的结构分布
在这段空间的最底部，存放着一个 struct thread_info 结构体，何以证明呢？
在Linux中有一个 union thread_union 共用体，其定义如下：
union thread_union {
#ifndef CONFIG_THREAD_INFO_IN_TASK
struct thread_info thread_info;
#endif
unsigned long stack[THREAD_SIZE/sizeof(long)];
};
其中的 stack 表示栈空间，大小为 THREAD_SIZE 个字节
union 表示是一个共用体，可以看出，thread_info 在位于这个栈的最底部，如下图所示：
Linux中发生系统调用时，会从用户态变成内核态，然后执行内核代码，当内核代码执行完之后，又会回到用户态执行用户代码
在进程从用户态变成内核态的时候，内核需要将用户态运行时寄存器的值保存下来，然后修改寄存器，当内核代码执行完之后，又将寄存器的值恢复，这些寄存器的值保存在哪里呢？
在内核栈的最高端，存放着一个 pt_regs 结构，这个结构包含了相关寄存器的定义，用户态寄存器的值就保存在这里，对于X86 32 位其定义如下：
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;
};
此外剩余的空间才是用作函数栈，栈是向下生长的，所以进程的内核栈就变成下面这个样子：
接下来看 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 */
};
thread_info 中有一个变量 task_struct，指向拥有这个内核栈的进程，如下所示：
2、current宏：
Linux内核中可以通过 current 宏来获取当前正在运行的进程，它的实现十分巧妙，下面我们一起来看一看：
#define get_current() (current_thread_info()->task)
#define current get_current()
current 通过 get_current()，进而调用 current_thread_info()->task
我们看一看 current_thread_info 的定义：
static inline struct thread_info *current_thread_info(void)
{
return (struct thread_info *)
(current_stack_pointer & ~(THREAD_SIZE - 1));
}
current_stack_pointer 表示当前栈顶寄存器的值，对于 X86 就是 esp，在内核态的时候，current_stack_pointer 表示内核栈中的某一个位置
THREAD_SIZE 我们上面说过是8K，THREAD_SIZE – 1 就是8K剩下的所有位，如下：
那么这个操作是什么意思呢？
(current_stack_pointer & ~(THREAD_SIZE - 1)
意思就是将 current_stack_pointer 的低12位清空
我们从这个 current_thread_info 函数可以看出，通过这个操作就可以获得 thread_info 对象，这是为什么呢？
这是因为，内核栈在申请的时候，总是 8K 对齐的，也就是说地址的低12位肯定为0
当进程在内核态运行的时候，栈顶指针总是指向这块申请的内核栈中的某一个区域，内核栈的大小最大也就8K，所以将当前栈顶指针的低12位置零就可以得到内核栈的基址
而 thread_info 存在于内核栈的栈底处，所以也就获取到了该进程对应的 thread_info 结构：
thread_info 结构中有一个 task_struct* 成员，指向该进程的 task_struct，所以也就可以获得该进程的 task_struct 结构
不禁感叹，Linux内核的实现真是巧妙啊！
文章参考：https://blog.csdn.net/weixin_42462202/article/details/102768721
转载请注明：XAMPP中文组官网 » Linux进程管理第一篇:进程数据结构