寇亚飞 + 原创作品转载请注明出处 + 《Linux内核分析》MOOC课程http://mooc.study.163.com/course/USTC-1000029000
实验内容
分析system_call中断处理过程
使用gdb跟踪分析一个系统调用内核函数(creat),系统调用列表参见http://codelab.shiyanlou.com/xref/linux-3.18.6/arch/x86/syscalls/syscall_32.tbl
实验步骤及结果
参考实验报告
实验分析
系统调用的执行过程可由下图大致表示
在系统调用结束返回(iret)前,可能会再次进行系统调用(call_schedule),调度过程中还可能发生进程上下文与中断上下文切换。系统完成一次调用后,会继续检检查任务队列,之后才执行iret返回。
实验总结
系统调用同之前学的系统上下文切换类似,它通过SAVE ALL保存上下文,调用内核函数,执行RESTORE_ALL并返回用户模式。
系统调用与中断的相同之处
- 保存现场
- 在系统调用时,我们需要SAVE_ALL,用于保存系统调用时的上下文
- 中断处理的第一步也需要保存中断现场
- 在终端执行完后,返回到原来被中断的地方继续运行。
- 确定中断信息
- 在系统调用时,我们需要将系统调用号通过eax传入,通过sys_call_table查询到调用的系统调用,然后跳转到相应的程序进行处理
- 中断处理时系统同样需要一个中断号,通过检索中断向量表,了解中断的类型和设备。
- 处理中断
- 跳转到相应的中断处理程序后,对中断进行处理。
- 返回
- 系统调用时最后要restore_all恢复系统调用时的现场,并用iret返回用户态。
- 同样,执行完中断处理程序,内核也要执行特定指令序列,恢复中断时现场,并使得进程回到用户态。
与用户态的函数库调用执行过程相比,系统调用执行过程的不同之处
- 不是通过“CALL”指令而是通过“INT”指令发起调用
- 不是通过“RET”指令,而是通过“IRET”指令完成调用返回
- 当到达内核态后,操作系统需要严格检查系统调用传递的参数,确保不破坏整个系统的安全性
- 执行系统调用可导致进程等待某事件发生,从而可引起进程切换