分析system_call中断处理过程

Posted 2020-06-29

分析system_call中断处理过程

上周我们使用gcc内嵌汇编调用系统调用，这次我们具体分析下过程。

将getpid嵌入menuos

代码从github下载，步骤如下：

1. 增加一个函数，getpid
2. 在main中添加MenuConfig("getpid","Show Pid", Getpid);
3. 重新编译 make roofs
4. 此时启动 执行getpid就可以看到打印出pid为1

 

menuos的原理

其实这个很简单，在上上周我们分析过linux内核的启动过程，1号进程，就是init，它的执行逻辑是/sbin/bin，所以这里的menuos就是编写的init。

这里注意，linux内核源码不包含/sbin/bin，一般的发行版使用的是FreeBSD的版本。

这里的menuos就是自己制作init，然后嵌入linux内核编译出的镜像。
所以在menuos中执行getpid，得到的pid为1，见上图。

中断处理

中断分为两种，一种是外中断，由外部的IO设备产生，另一种是内中断，也称为异常，由CPU内部产生。

这里涉及到一个很重要的概念，叫做中断上下文。

CPU的运行状态，分为以下三种：

1. 内核态，运行于进程上下文，内核代表进程运行于内核空间。
2. 内核态，运行于中断上下文，内核代表硬件运行于内核空间。
3. 用户态，运行于用户空间。

从上面，我们可以看出，中断上下文不与任何的进程相关联，仅仅运行在内核空间，而且一般只访问内核数据。

这里顺便总结下进程上下文：

1. 用户级上下文: 正文、数据、用户堆栈以及共享存储区；
2. 寄存器上下文: 通用寄存器、程序寄存器(IP)、处理器状态寄存器(EFLAGS)、栈指针(ESP)；
3. 系统级上下文: 进程控制块task_struct、内存管理信息(mm_struct、vm_area_struct、pgd、pte)、内核栈。

其实就是包含三个内容：用户数据、硬件状态（主要是寄存器）、内核数据。
所以，当发生进程调度时，要将三个上下文全部进行切换。
当进行系统调用时，仅仅需要切换寄存器上下文。

相比进程上下文，中断上下文仅仅包含一些寄存器的信息。发生中断时，所谓的保护现场和恢复现场，指的就是这些寄存器信息。

分析system_call

代码如下：

# system call handler stub
ENTRY(system_call)
	RING0_INT_FRAME			# can‘t unwind into user space anyway
	ASM_CLAC
	pushl_cfi %eax			# save orig_eax
	SAVE_ALL				# 保存系统寄存器信息
	GET_THREAD_INFO(%ebp)   # 获取thread_info结构的信息
					# system call tracing in operation / emulation
	testl $_TIF_WORK_SYSCALL_ENTRY,TI_flags(%ebp) # 测试是否有系统跟踪
	jnz syscall_trace_entry   # 如果有系统跟踪，先执行，然后再回来
	cmpl $(NR_syscalls), %eax # 比较eax中的系统调用号和最大syscall，超过则无效
	jae syscall_badsys # 无效的系统调用 直接返回
syscall_call:
	call *sys_call_table(,%eax,4) # 调用实际的系统调用程序
syscall_after_call:
	movl %eax,PT_EAX(%esp)		# 将系统调用的返回值eax存储在栈中
syscall_exit:
	LOCKDEP_SYS_EXIT
	DISABLE_INTERRUPTS(CLBR_ANY)	# make sure we don‘t miss an interrupt
					# setting need_resched or sigpending
					# between sampling and the iret
	TRACE_IRQS_OFF
	movl TI_flags(%ebp), %ecx
	testl $_TIF_ALLWORK_MASK, %ecx	# 检测是否所有工作已完成
	jne syscall_exit_work  			# 未完成，则去执行这些任务
restore_all:
	TRACE_IRQS_IRET			# iret 从系统调用返回

这段代码的逻辑主要就是：

1. 保存寄存器上下文，
2. 检查系统调用号是否合法
3. 执行系统调用
4. 检查是否还有别的工作需要完成
5. 退出系统调用，返回到用户态

我们继续跟踪里面的syscall_exit_work，它用来处理系统调用之后，未完成的工作

syscall_exit_work:
	testl $_TIF_WORK_SYSCALL_EXIT, %ecx # 测试syscall的工作完成
	jz work_pending
	TRACE_IRQS_ON
	ENABLE_INTERRUPTS(CLBR_ANY)	# could let syscall_trace_leave() call
					# schedule() instead
	movl %esp, %eax
	call syscall_trace_leave
	jmp resume_userspace
END(syscall_exit_work)

这一段的主要作用还是进入work_pending

work_pending代码：

work_pending:
	testb $_TIF_NEED_RESCHED, %cl  # 判断是否需要调度
	jz work_notifysig   # 不需要则跳转到work_notifysig
work_resched:
	call schedule   # 调度进程
	LOCKDEP_SYS_EXIT
	DISABLE_INTERRUPTS(CLBR_ANY)	# make sure we don‘t miss an interrupt
					# setting need_resched or sigpending
					# between sampling and the iret
	TRACE_IRQS_OFF
	movl TI_flags(%ebp), %ecx
	andl $_TIF_WORK_MASK, %ecx	# 是否所有工作都已经做完
	jz restore_all  			# 是则退出
	testb $_TIF_NEED_RESCHED, %cl # 测试是否需要调度
	jnz work_resched  			# 重新执行调度代码

这段的逻辑很清楚

1. 先检查是否需要调度，
2. 如果是，则进行进程调度，之后再次判断。
3. 如果不需要调度，那么去执行work_notifysig，处理信号

work_notifysig代码：

work_notifysig:				# 投递信号
#ifdef CONFIG_VM86
	testl $X86_EFLAGS_VM, PT_EFLAGS(%esp) # 判断8086虚模式，也就是保护模式
	movl %esp, %eax
	jne work_notifysig_v86		# 返回到内核空间
1:
#else
	movl %esp, %eax
#endif
	TRACE_IRQS_ON
	ENABLE_INTERRUPTS(CLBR_NONE)
	movb PT_CS(%esp), %bl
	andb $SEGMENT_RPL_MASK, %bl
	cmpb $USER_RPL, %bl
	jb resume_kernel
	xorl %edx, %edx
	call do_notify_resume  # 将信号投递到进程
	jmp resume_userspace  # 恢复用户空间
#ifdef CONFIG_VM86			# 如果是VM86模式，需要保存状态信息
	ALIGN
work_notifysig_v86:
	pushl_cfi %ecx			# save ti_flags for do_notify_resume
	call save_v86_state		# 保存虚模式下的状态
	popl_cfi %ecx
	movl %eax, %esp
	jmp 1b                  # 跳转到上面的代码，执行do_notify_resume
#endif
END(work_pending)

这段代码主要是处理信号：

1. 先检查是否是8086保护模式
2. 如果是，那么需要先保存虚模式下的状态信息
3. 然后跳转到之前的代码继续执行
4. 将信号投递到进程
5. 恢复用户空间

之后就是返回系统调用

流程图总结

如图：

总结

系统调用中断，本质上也是一个保存状态、进行处理、返回并恢复状态的过程。

署名信息

李泽源 
原创作品转载请注明出处 ：《Linux内核分析》MOOC课程 http://mooc.study.163.com/course/USTC-1000029000