2021-2022-1 20222821《Linux内核原理与分析》第六周作业

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

实验要求

• 使用 gdb 跟踪分析一个系统调用内核函数（您上周选择的那一个系统调用），系统调用列表参见 torvalds/linux。推荐在实验楼 Linux 虚拟机环境下完成实验。
• 根据本周所学知识分析系统调用的过程，从 system_call 开始到 iret 结束之间的整个过程，并画出简要准确的流程图，撰写一篇署名博客，并在博客文章中注明“真实姓名（与最后申请证书的姓名务必一致） + 原创作品转载请注明出处 + 《Linux 内核分析》MOOC 课程 Linux内核分析 - 网易云课堂”，博客内容的具体要求如下：
  • 题目自拟，内容围绕系统调用 system_call 的处理过程进行；
  • 博客内容中需要仔细分析 system_call 对应的汇编代码的工作过程，特别注意系统调用返回 iret 之前的进程调度时机等。
  • 总结部分需要阐明自己对“系统调用处理过程”的理解，进一步推广到一般的中断处理过程。

请提交博客文章 URL 到网易云课堂 MOOC 平台，编辑成一个链接可以直接点击打开。(学堂在线上的学员注意提交博客 URL 到学堂在线上)

实验过程

cd ~/LinuxKernel
cd menu
make rootfs

在test.c文件中增加Hello函数和在main函数中增加MenuConfig语句，编译并执行：

int Hello(int argc,char* argv[])
{
    int usr;
    usr=getuid();
    printf("Hello, I am 20222821! The id is %d\n",usr);
    return 0;
}

MenuConfig("hello","Return UID",Hello);

make rootfs

输入hello

使用gdb跟踪系统调用内核函数

# shell1中启动内核
cd ~/LinuxKernel
qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img -S -s

# shell2中使用gdb调试
cd ~/LinuxKernel
gdb
file linux-3.18.6/vmlinux
target remote:1234
b start_kernel
c

在start_kernel处设置断点，输入c继续执行至start_kernel

 在sys_time处设置断点，启动MenuOS后执行time命令，time命令仅执行一半

 

 

 使用l打印sys_time对应的代码

分析系统调用的处理过程
系统调用机制的初始化是在 start_kernel 中的 trap_init()(定义在/arch/x86/kernel/traps.c中)里进行的：

#ifdef CONFIG_X86_32
   set_system_trap_gate(SYSCALL_VECTOR, &system_call); //SYSCALL_VECTOR系统调用的中断向量，&system_call是 system_call的入口，一旦执行int 0x80，CPU就会立即跳转到此处
   set_bit(SYSCALL_VECTOR, used_vectors);
#endif

在 /arch/x86/include/asm/irq_vectors.h 中查看 SYSCALL_VECTOR 的值，的确是0x80:

#ifdef CONFIG_X86_32
# define SYSCALL_VECTOR         0x80
#endif

system_call 的相关代码的位置是 /arch/x86/kernel/entry_32 ：

ENTRY(system_call)
     RING0_INT_FRAME    
     ASM_CLAC        
     pushl_cfi %eax            //保存系统调用号；
     SAVE_ALL                  //可以用到的所有CPU寄存器保存到栈中
     GET_THREAD_INFO(%ebp)     //ebp用于存放当前进程thread_info结构的地址
     testl $_TIF_WORK_SYSCALL_ENTRY,TI_flags(%ebp)
     jnz syscall_trace_entry
     cmpl $(nr_syscalls), %eax  //检查系统调用号（系统调用号应小于NR_syscalls）,
     jae syscall_badsys         //不合法，跳入到异常处理
 syscall_call:
     call *sys_call_table(,%eax,4) //合法，对照系统调用号在系统调用表中寻找相应服务例程
     movl %eax,PT_EAX(%esp)        //保存返回值到栈中
 syscall_exit:  
     testl $_TIF_ALLWORK_MASK, %ecx   //检查是否需要处理信号
     jne syscall_exit_work        //需要,进入 syscall_exit_work
 restore_all: 
     TRACE_IRQS_IRET              //不需要,执行restore_all恢复，返回用户态
 irq_return:
     INTERRUPT_RETURN             //相当于iret

系统调用分析流程图如下：

system_call流程如上图所示。系统调用的工作机制在start_kernel里初始化后，一旦执行int 0x80，cpu就直接跳转到system_call这个位置来执行。当一个系统调用发生时，进入内核处理这个系统调用，系统调用的内核服务程序在服务结束返回到用户态之前，可能会发生进程调度，在进程调度中会发生进程上下文切换。从系统调用处理进程的入口开始，可以看到SAVE_ALL保存现场，然后找到system_call和sys_call_table，之后restore_all和最后一个INTERRUPT_RETURN(iret)用于恢复现场并返回系统调用到用户态结束。其中，syscall_exit_work需要跳转到work_pending，里面有work_notifysig处理信号。还有work_resched是需要重新调度的，这里是进程调度的时机点call schedule,调度完后才会跳转到restore_all，之后执行恢复现场操作。