Linux内核分析之简析system_call中断处理过程

SA16225055冯金明

原创作品转载请注明出处 

《Linux内核分析》MOOC课程http://mooc.study.163.com/course/USTC-1000029000

实验内容

实验要求：

1.使用gdb跟踪分析一个系统调用内核函数（必须选用上周所使用的系统调用）

2.根据本周所学知识分析系统调用的过程，从system_call开始到iret结束之间的整个过程，并画出简要准确的流程图

实验具体操作及相关截图：

1.修改test.c文件和重新生成根文件系统

添加Getpid()和Getpid_Asm()两个函数

添加两个函数的调用命令

重新编译和生成新的文件系统

系统启动显示结果：

2.跟踪系统调用

创建sys_getpid的断点：

s命令的单步调试：

简析system_call中断处理过程

system_call相关的具体代码如下图所示（在kernel/entry_32.s中）

此段代码 都是汇编代码所写，晦涩难懂。因此，使用孟宁老师缩写的伪代码来进行分析，实为明智之选。

定义两个两个宏，分别为：SAVE_ALL和RESTORE_ALL

14行：SAVE_ALL 保存现场

16行：可以跳转至相应的系统调用处理函数

17行：保存中断处理的相关返回值

18-20行：检测是否有任务需要执行，如有，则跳转至syscall_exit_work

21行：restore_all 恢复现场

23行：irq_return 系统调用返回，调用结束

下面将对syscall_exit_work进行简单分析：

26-28行：判断是否需要处理信号，如需要则跳转至work_pending

29行：结束任务处理

30-32行：work_notifysig 进行信号处理

33-35行：可能会存在进程调度，则会执行call schedule 然后再跳转至restore_all 返回系统调用

根据以上所分析得大致流程，可以画出我所理解的system_call中断处理过程的流程图：

总结

system_call是Linux中所有系统调用的入口点，每个系统调用都至少需要有一个参数，即由eax传递进入的系统调用号。call *sys_call_table(,%eax,4)函数，就是通过eax传递进来的系统调用号来寻找相信的系统调用处理函数。系统调用本质上是一种特殊的中断，所以它也需要进行现场的保存和结束调用后的恢复。在系统调用处理的同时，是会存在信号处理或者进程调度的，其中的工作切换还是很麻烦，在此我就不做详细讲解，分析到此，谢谢各位大佬的查阅。如有不足，还请大家指出！！！