概述
昨天在do_fork实现–上中学习了do_fork创建的前半段,今天我们接着继续分析copy_Process函数
分析了copy_fs, copy_files, copy_signal, copy_sighand, copy_mm,今天接着分析copy_thread, copy_thread是和架构相关的,需要到具体的ARCH目录下去看
在分析copy_thread之前,我们先看几个知识点:
重点结构体学习
struct task_struct {
struct thread_info thread_info;
void* stack;
/* CPU-specific state of this task: */
struct thread_struct thread;
}
上次在学threadinfo和内核栈的时候介绍过thread_info和stack的关系,今天再需要介绍一个结构体struct thread_struct结构。从注释上看这个结构体是个CPU体系相关的。
struct cpu_context {
unsigned long x19;
unsigned long x20;
unsigned long x21;
unsigned long x22;
unsigned long x23;
unsigned long x24;
unsigned long x25;
unsigned long x26;
unsigned long x27;
unsigned long x28;
unsigned long fp;
unsigned long sp;
unsigned long pc;
};
struct thread_struct {
struct cpu_context cpu_context; /* cpu context */
unsigned int fpsimd_cpu;
void *sve_state; /* SVE registers, if any */
unsigned int sve_vl; /* SVE vector length */
unsigned int sve_vl_onexec; /* SVE vl after next exec */
unsigned long fault_address; /* fault info */
unsigned long fault_code; /* ESR_EL1 value */
struct debug_info debug; /* debugging */
};
当然了我们目前只关注struct cpu_context结构,此结构会在进程切换时用来保存上一个进程的寄存器的值。一般会需要切换出去的进程的x19-x28以及fp, sp, lr寄存器保存到cpu_context中。这个会在进程调度文章中有详细描述。
再看一个结构体:
struct user_pt_regs {
__u64 regs[31];
__u64 sp;
__u64 pc;
__u64 pstate;
};
/*
* This struct defines the way the registers are stored on the stack during an
* exception. Note that sizeof(struct pt_regs) has to be a multiple of 16 (for
* stack alignment). struct user_pt_regs must form a prefix of struct pt_regs.
*/
struct pt_regs {
union {
struct user_pt_regs user_regs;
struct {
u64 regs[31];
u64 sp;
u64 pc;
u64 pstate;
};
};
u64 orig_x0;
#ifdef __AARCH64EB__
u32 unused2;
s32 syscallno;
#else
s32 syscallno;
u32 unused2;
#endif
u64 orig_addr_limit;
u64 unused; // maintain 16 byte alignment
u64 stackframe[2];
};
从注释上看struct pt_regs主要的作用是用来保存,当用户空间的进程发生异常(系统调用,中断等)进入内核模式,则需要将用户进程当前的寄存器状态保存到pt_regs中。
struct thread_struct & struct pt_regs的区别
- thread_struct结构体主要是在内核态两个进程发生切换时,thread_struct用来保存上一个进程的相关寄存器。
- pt_regs结构体主要是当用户态的进程陷入到内核态时,需要使用pt_regs来保存用户态进程的寄存器状态。
copy_process继续分析
static inline int copy_thread_tls(
unsigned long clone_flags, unsigned long sp, unsigned long arg,
struct task_struct *p, unsigned long tls)
{
return copy_thread(clone_flags, sp, arg, p);
}
//代码路径:arch/arm64/kernel/process.c
int copy_thread(unsigned long clone_flags, unsigned long stack_start,
unsigned long stk_sz, struct task_struct *p)
{
struct pt_regs *childregs = task_pt_regs(p);
memset(&p->thread.cpu_context, 0, sizeof(struct cpu_context));
在copy_thread就会涉及到我们刚才上面学习的两个结构体,我们来做简单的分析下。
- struct pt_regs *childregs = task_pt_regs(p); 获取到新创建进程的pt_regs结构,看下是如何获取的。
#define task_stack_page(task) ((void *)(task)->stack)
#define task_pt_regs(p)
((struct pt_regs *)(THREAD_SIZE + task_stack_page(p)) - 1)
- 很清楚,通过进程的task_struct结构获取到内核栈stack成员,然后加上THREAD_SIZE就是内核栈的大小,所以pt_regs是存储在内核栈的栈底的。
- memset(&p->thread.cpu_context, 0, sizeof(struct cpu_context)); 将新创建进程的thread_struct结构清空
我们继续分析copy_thread函数,为了更清楚的表述,我们分段描述copy_thread函数
if (likely(!(p->flags & PF_KTHREAD))) { //用户进程
*childregs = *current_pt_regs();
childregs->regs[0] = 0;
/*
* Read the current TLS pointer from tpidr_el0 as it may be
* out-of-sync with the saved value.
*/
*task_user_tls(p) = read_sysreg(tpidr_el0);
if (stack_start) {
if (is_compat_thread(task_thread_info(p)))
childregs->compat_sp = stack_start;
else
childregs->sp = stack_start;
}
/*
* If a TLS pointer was passed to clone (4th argument), use it
* for the new thread.
*/
if (clone_flags & CLONE_SETTLS)
p->thread.uw.tp_value = childregs->regs[3];
- 接着就会去判断当前进程是不是内核线程,很明显没有设置PF_KTHREAD标志
- 通过current_pt_regs获取当前进程的pt_regs, 然后将当前进程的pt_regs结构的值赋值给新创建进程的pt_regs
- childregs->regs[0] = 0; 这里操作的原因是,一般用户态通过系统调度陷入到内核态后处理完毕后会通过x0寄存器设置返回值的,这里首先将返回值设置为0
- 如果stack_start设置了,这个是在clone时候传递的参数。当创建内核线程或者通过pthread_create会设置此值,此值就对应的是线程的回调处理函数
- 如果stack_start设置了,则这里是pthread_create创建的用户线程,则设置用户态的SP_EL0指针,childregs->sp = stack_start;
} else {
memset(childregs, 0, sizeof(struct pt_regs));
childregs->pstate = PSR_MODE_EL1h;
if (IS_ENABLED(CONFIG_ARM64_UAO) &&
cpus_have_const_cap(ARM64_HAS_UAO))
childregs->pstate |= PSR_UAO_BIT;
if (arm64_get_ssbd_state() == ARM64_SSBD_FORCE_DISABLE)
childregs->pstate |= PSR_SSBS_BIT;
p->thread.cpu_context.x19 = stack_start;
p->thread.cpu_context.x20 = stk_sz;
}
- 走到这里,则当前创建的是一个内核线程。如果是内核线程的话则不需要pt_regs结构,则需要清空memset(childregs, 0, sizeof(struct pt_regs));
- childregs->pstate = PSR_MODE_EL1h; 设置当前进程是pstate是在EL1模式下,ARM64架构中使用pstate来描述当前处理器模式.
- p->thread.cpu_context.x19 = stack_start; 创建内核线程的时候会传递内核线程的回调函数到stack_start的参数,将其设置到x19寄存器。
- p->thread.cpu_context.x20 = stk_sz; 通用创建内核线程的时候也会传递回调函数的参数,设置到x20寄存器
p->thread.cpu_context.pc = (unsigned long)ret_from_fork;
p->thread.cpu_context.sp = (unsigned long)childregs;
asmlinkage void ret_from_fork(void) asm("ret_from_fork")
- 设置新创建进程的pc指针为ret_from_fork,当新创建的进程运行时会从ret_from_fork运行,ret_from_fork是个汇编语言编写的
- 设置新创建进程的SP_EL1的值为childregs, SP_EL1则是指向内核栈的栈底处。
我们用一张图简单的总结下:
至此分析完毕了copy_thread函数。
继续分析copy_process函数
if (pid != &init_struct_pid) {
pid = alloc_pid(p->nsproxy->pid_ns_for_children);
if (IS_ERR(pid)) {
retval = PTR_ERR(pid);
goto bad_fork_cleanup_thread;
}
}
/* ok, now we should be set up.. */
p->pid = pid_nr(pid);
if (clone_flags & CLONE_THREAD) {
p->exit_signal = -1;
p->group_leader = current->group_leader;
p->tgid = current->tgid;
} else {
if (clone_flags & CLONE_PARENT)
p->exit_signal = current->group_leader->exit_signal;
else
p->exit_signal = (clone_flags & CSIGNAL);
p->group_leader = p;
p->tgid = p->pid;
}
total_forks++;
return p;
- init_struct_pid是0号进程静态分配的pid,如果不相等的话则分配struct pid的结构体
- pid_nr(pid) 真正的返回pid的number
- 如果设置了CLONE_THREAD,则创建的新进程是一个线程,则退出信号设置为-1, 因为线程退出不需要发送信号给父进程。
- 因为创建的是一个线程,则group_leader和tgid和当前进程保持一致
- 如果设置了CLONE_PARENT,则新创建的进程和当前进程是兄弟关系,则退出信号跟踪当前进程的。
- 设置新创建进程的线程组的组长和tgid都是自己
- 增加一次fork的次数,返回新创建进程的task_struct结构。
至此do_fork的源代码就分析完毕了。do_fork的源代码比较长,在这个过程中只讲解了大概的主干分支,细节有可能没分析到,感兴趣的小伙伴去分析。
新创建的进程第一次运行
当copy_process返回新创建进程的task_struct结构后,则wake_up_new_task来唤醒进程,此函数中设置进程的状态为TASK_RUNNING, 选择需要在那个cpu上运行,然后将此进程加入到该cpu的对应的就绪队列中,等待CPU的调度。
当调度器选择此进程运行时,则就会运行之前在copy_thread中设置的ret_from_fork函数
/* GPRs used by entry code */
tsk .req x28 // current thread_info
/*
* Return the current thread_info.
*/
.macro get_thread_info, rd
mrs rd, sp_el0
.endm
/*
* This is how we return from a fork.
*/
ENTRY(ret_from_fork)
bl schedule_tail
cbz x19, 1f // not a kernel thread
mov x0, x20
blr x19
1: get_thread_info tsk
b ret_to_user
ENDPROC(ret_from_fork)
- schedule_tail 此函数主要是为上一个切换出去的进程做一个扫尾的工作,在进程切换小节详解
- 接着就判断x19的值是不是为0,在copy_thread中如果是一个内核线程会设置x19的。
- 如果x19的值不为0,则会通过blr x19,去处理内核线程的回调函数的。其中x20要赋值给x0, x0一般当做参数传递
- 如果x19的值是为0的话,则会跳到标号1处。
- get_thread_info会去读SP_EL0的值,SP_EL0的值存储的是当前进程的thread_info的值。
- tsk代表的是x28,则使用x28存储当前进程thread_info的值,然后跳转到ret_to_user处返回用户空间
ret_to_user分析
/*
* Ok, we need to do extra processing, enter the slow path.
*/
work_pending:
mov x0, sp // 'regs'
bl do_notify_resume
#ifdef CONFIG_TRACE_IRQFLAGS
bl trace_hardirqs_on // enabled while in userspace
#endif
ldr x1, [tsk, #TSK_TI_FLAGS] // re-check for single-step
b finish_ret_to_user
/*
* "slow" syscall return path.
*/
ret_to_user:
disable_daif
ldr x1, [tsk, #TSK_TI_FLAGS]
and x2, x1, #_TIF_WORK_MASK
cbnz x2, work_pending
finish_ret_to_user:
enable_step_tsk x1, x2
#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
bl stackleak_erase
#endif
kernel_exit 0
ENDPROC(ret_to_user)
- ret_to_user的第一句就是disable_daif, daif是ARM64 PSTATE代表当前处理器状态的,disable_daif则就会关闭DAIF各个位,D(debug)A(Serror)I(IRQ)F(FIQ)
- ldr x1, [tsk, #TSK_TI_FLAGS], 将thread_info.flags的值赋值给X1
- and x2, x1, #_TIF_WORK_MASK, 将X1的值和_TIF_WORK_MASK的值或,_TIF_WORK_MASK是一个宏,里面包含了很多字段,比如是否需要调度字段_TIF_NEED_RESCHED等
- cbnz x2, work_pending 当X2的值不等于0时,则跳转到work_pending做一个慢速的ret过程,在do_notify_resume中检查是否要对pending的任务做进一步的操作
- 然后调用kernel_exit 0返回到用户空间
kernel_exit分析
kernel_exit的代码有点长,分段来简单看下。
.macro kernel_exit, el
.if el != 0
disable_daif
/* Restore the task's original addr_limit. */
ldr x20, [sp, #S_ORIG_ADDR_LIMIT]
str x20, [tsk, #TSK_TI_ADDR_LIMIT]
/* No need to restore UAO, it will be restored from SPSR_EL1 */
.endif
ldp x21, x22, [sp, #S_PC] // load ELR, SPSR
.if el == 0
ct_user_enter
.endif
- 当el不等于0时,此时还是调用disable_daif来关闭中断,debug等功能
- 恢复task原始的add_limit,没研究这东西是做啥的,不关系。
- ldp x21, x22, [sp, #S_PC] ,其中SP是在copy_thread的时候设置了,sp是指向了struct pt_regs结构的。而此条指令是load pt_regs结构中的PC=X21, PSTATE=X22寄存器
.if el == 0
ldr x23, [sp, #S_SP] // load return stack pointer
msr sp_el0, x23
tst x22, #PSR_MODE32_BIT // native task?
b.eq 3f
- 如果el=0的话,ldr x23, [sp, #S_SP] 这条指令是返回struct pt_regs结构中的SP=X23
- msr sp_el0, x23 #将x23的值设置到SP_EL0寄存器中,SP_EL0就是用户态EL0的堆栈寄存器
3:
apply_ssbd 0, x0, x1
.endif
msr elr_el1, x21 // set up the return data
msr spsr_el1, x22
ldp x0, x1, [sp, #16 * 0]
ldp x2, x3, [sp, #16 * 1]
ldp x4, x5, [sp, #16 * 2]
ldp x6, x7, [sp, #16 * 3]
ldp x8, x9, [sp, #16 * 4]
ldp x10, x11, [sp, #16 * 5]
ldp x12, x13, [sp, #16 * 6]
ldp x14, x15, [sp, #16 * 7]
ldp x16, x17, [sp, #16 * 8]
ldp x18, x19, [sp, #16 * 9]
ldp x20, x21, [sp, #16 * 10]
ldp x22, x23, [sp, #16 * 11]
ldp x24, x25, [sp, #16 * 12]
ldp x26, x27, [sp, #16 * 13]
ldp x28, x29, [sp, #16 * 14]
ldr lr, [sp, #S_LR]
add sp, sp, #S_FRAME_SIZE // restore sp
DEFINE(S_LR, offsetof(struct pt_regs, regs[30]));
DEFINE(S_FRAME_SIZE, sizeof(struct pt_regs))
- 刚才已经从x21,x22获取了pc和pstate的值,则通过msr指令将x21和x22的设置到elr_el1,spsr_el1寄存器中。
- 接着就是从pt_regs结构体宏恢复x0-x29寄存器的值。这些寄存器都是从用户态陷入到内核态时保存的。现在给恢复回去
- ldr lr, [sp, #S_LR] 获取LR寄存器的值,LR就是连接返回地址。
- add sp, sp, #S_FRAME_SIZE, 给sp加上pt_regs结构体的大小,则恢复SP堆栈指针的值
.if el == 0
alternative_insn eret, nop, ARM64_UNMAP_KERNEL_AT_EL0
#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
bne 4f
msr far_el1, x30
tramp_alias x30, tramp_exit_native
br x30
4:
tramp_alias x30, tramp_exit_compat
br x30
#endif
.else
eret
.endif
sb
.endm
- 等el=0时,则br跳转到x30返回,x30就是lr寄存器
- 否则通过eret返回。
这个是kernel_exit的实现,大家有兴趣的话可以看看kernel_entry的实现,里面会有保存寄存器的过程。这里就不分析了。
至此我们关系do_fork的实现分析完毕,总结下我们都涉及的内容
- copy_process的实现,有几个重点
- sched_fork
- copy_mm
- copy_thread
- 这三个函数是重点,调度会在后面学习调度的时候分析。mm会在内存管理的时候分析
- 新创建进程的第一次运行
- ret_to_user的解释
- kernel_exit的解释
最后
以上就是眯眯眼发夹为你收集整理的do_fork实现--下重点结构体学习struct thread_struct & struct pt_regs的区别copy_process继续分析继续分析copy_process函数新创建的进程第一次运行ret_to_user分析kernel_exit分析的全部内容,希望文章能够帮你解决do_fork实现--下重点结构体学习struct thread_struct & struct pt_regs的区别copy_process继续分析继续分析copy_process函数新创建的进程第一次运行ret_to_user分析kernel_exit分析所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复