实验5 :分析system_call中断处理过程

分析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

 

时间: 2024-12-25 20:50:42

实验5 :分析system_call中断处理过程的相关文章

Linux内核分析—实验五分析system_call中断处理过程

郑斌 + 原创作品转载请注明出处 + <Linux内核分析>MOOC课程http://mooc.study.163.com/course/USTC-1000029000 实验要求: 使用gdb跟踪分析一个系统调用内核函数(您上周选择的那一个系统调用),系统调用列表参见http://codelab.shiyanlou.com/xref/linux-3.18.6/arch/x86/syscalls/syscall_32.tbl ,推荐在实验楼Linux虚拟机环境下完成实验. 根据本周所学知识分析系

通过系统调用分析system_call中断处理过程

罗冲 + 原创作品转载请注明出处 + <Linux内核分析>MOOC课程http://mooc.study.163.com/course/USTC-1000029000 1. 实验准备 1.1 环境准备 下载linux3.18.6的源代码. 按照http://mooc.study.163.com/learn/USTC-1000029000?tid=2001214000#/learn/content?type=detail&id=2001400011给出步骤进行编译 # 下载内核源代码编

实验五:分析system_call中断处理过程

原创作品转载请注明出处<Linux内核分析>MOOC课程http://mooc.study.163.com/course/USTC-1000029000 如果我写的不好或者有误的地方请留言 题目自拟,内容围绕系统调用system_call的处理过程进行: 博客内容中需要仔细分析system_call对应的汇编代码的工作过程,特别注意系统调用返回iret之前的进程调度时机等. 总结部分需要阐明自己对“系统调用处理过程”的理解,进一步推广到一般的中断处理过程. 实验报告: 1.将myfork()和

分析system_call中断处理过程

李亚健    <Linux内核分析>MOOC课程http://mooc.study.163.com/course/USTC-1000029000 一.实验过程: 使用gdb跟踪分析一个系统调用内核函数(上周选择的那一个系统调用) 1.进入实验楼环境,进入LinuxKernel: rm menu -rf git clone https://github.com/mengning/menu.git  从github中克隆 cd menu make rootfs 2.给menuOS增加自己的内容:

通过实验分析system_call中断处理过程

作者:吴乐 山东师范大学 <Linux内核分析>MOOC课程http://mooc.study.163.com/course/USTC-1000029000 本实验目的:通过以一个简单的menu小程序,跟踪系统调用的过程,分析与总结系统调用的机制和三层进入的过程. 一.实验步骤 1.使用gdb在sys_time处设置断点并list找到的代码 2.用s(step)跟踪断点 3.当进入system_call的时候gdb无法继续跟踪,实验结束,找到源代码进行分析 二.system_call对应的汇编

linux内核分析第五周-分析system_call中断处理过程

本实验目的:通过以一个简单的menu小程序,跟踪系统调用的过程,分析与总结系统调用的机制和三层进入的过程. 实验原理:系统调用处理过程与中断处理的机制 系统调用是通过软中断指令 INT 0x80 实现的,而这条INT 0x80指令就被封装在C库的函数中.(软中断和我们常说的硬中断不同之处在于,软中断是由指令触发的,而不是由硬件外设引起的.)INT 0x80 这条指令的执行会让系统跳转到一个预设的内核空间地址,它指向系统调用处理程序,即system_call函数. system_call函数是怎么

system_call中断处理过程

使用gdb跟踪分析一个系统调用内核函数(您上周选择那一个系统调用),系统调用列表参见http://codelab.shiyanlou.com/xref/linux-3.18.6/arch/x86/syscalls/syscall_32.tbl ,推荐在实验楼Linux虚拟机环境下完成实验. 根据本周所学知识分析系统调用的过程,从system_call开始到iret结束之间的整个过程,并画出简要准确的流程图,

Linux内核system_call中断处理过程

在相应的test.c中添加getpid和getpid-asm的函数,使Menu实现getpid和getpid-asm的命令. 添加完成后,修改menu目录下的Makefile文件中的 qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img变为qemu-system-i386 -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img 然后执行在menu目录

《Linux内核分析》 week5作业-system call中断处理过程

一.使用gdb跟踪分析一个系统调用内核函数 1.在test.c文件中添加time函数与采用c语言内嵌汇编的time函数.具体实现请看下图. 2.然后在main函数中添加MenuConfig函数,进行注册.这样当Menuos运行起来时,界面就会多出time与time-asm选项. 3.通过make rootfs命令运行 采用gdb调试的过程 qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img -s -S gdb fi