网易云课堂 Linux内核分析（五）

寇亚飞 + 原创作品转载请注明出处 + 《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”指令完成调用返回
• 当到达内核态后，操作系统需要严格检查系统调用传递的参数，确保不破坏整个系统的安全性
• 执行系统调用可导致进程等待某事件发生，从而可引起进程切换