2017-2018-1 20179215《Linux内核原理与分析》第六周作业
一、实验部分：使用gdb跟踪分析一个系统调用内核函数（上周选择的那一个系统调用）。
【第一部分】 根据要求完成第一部分，步骤如下：
①更新menu代码到最新版
②在原有代码中加入C函数、汇编函数
int Getuid(int argc,char *argv[])
{
int uid;
uid=getuid();
printf("uid=%d\n",uid);
return 0;
}
int GetuidAsm()
{
int uid;
uid=getuid();
asm volatile(
"mov $0,%%ebx\n\t"
"mov $0x18,%%eax\n\t"
"int $0x80\n\t"
"mov %%eax,%0\n\t"
:"=m"(uid)
);
printf("uid=%d\n",uid);
return 0;
}
③在main函数中加入getuid以及getuid-asm的makeconfig
MenuConfig("getuid","Show System User",Getuid);
MenuConfig("getuid_asm","Show System User(asm)",GetuidAsm);
④make rootfs
⑤可以看到qemu中增加了我们先前添加的命令
⑥分别执行新增的命令
【第二部分】gdb跟踪分析一个系统调用内核函数
①进入gdb调试
②设置断点，继续执行，得到结果：
③查看我所选用的系统调用的函数：
④设置断点在sys_getuid16处，发现执行命令getuid时并没有停下：
⑤反而在执行getuid_asm时停下了：
⑥直接结束若干次单步执行，然后继续往下单步执行，发现出现了进程调度函数，返回了进程调度中的一个当前进程任务的值。
⑦设置断点于system_ call处。发现可停，而继续执行时，刚才停下的getuid_asm也返回了值。
【第三部分】system_call到iret过程
系统调用在内核代码中的工作机制和初始化
1.系统调用机制的初始化
trap_init();
#ifdef CONFIG_X86_32
set_ system_trap_ gate(SYSCALL_VECTOR,&system_call);//两个参数分别代表：系统调用的中断向量；汇编代码的入口，一旦执行时int 0x80，系统就跳转至此执行
set_bit(SYSCALL_VECTOR,used-vectors);
#endif
2.理解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 从系统调用返回
System_ Call中的关键部分：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 //返回用户空间,只需要检查need_resched
END(syscall_exit_work)
该过程为系统调用完成后如何退出调用的过程,其中比较重要的是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 // 重新执行调度代码
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
ALIGN
work_notifysig_v86:
pushl_cfi %ecx # save ti_flags for do_notify_resume
call save_v86_state // 保存VM86模式下的CPU信息
popl_cfi %ecx
movl %eax, %esp
jmp 1b
#endif
END(work_pending)
System_Call的基本处理流程为：
首先保存中断上下文（SAVE_ALL，也就是CPU状态，包括各个寄存器）,判断请求的系统调用是否有效,然后call *sys_call_table(,%eax,4)通过系统查询系统调用查到相应的系统调用程序地址，执行相应的系统调用,系统调用完后，返回系统调用的返回值,关闭中断响应，检测系统调用的所有工作是否已经完成，如果完成则进行syscall_ exit_ work(完成系统调用退出工作）,最后restore_all(恢复中断请求响应),返回用户态
总结：具体的系统调用与系统调用号绑定，然后都记载在一个系统调用表内，每次使用系统调用时都是通过这样的绑定关系，由系统调用号去找系统调用表然后查找到所对应的系统调用的位置。同理，中断处理过程也是一样的，它也是经由中断向量号作为索引去查表，然后执行相应的具体的中断处理程序去处理中断。简而言之就是“两个号&两张表”。
整体的流程图：
| 存在的疑问： |
二、读书笔记
| 1、同步 |
所谓同步，其实防止在临界区中形成竞争条件。如果临界区里是原子操作(即整个操作完成前不会被打断)，那么自然就不会出竞争条件。但在实际应用中，临界区中的代码往往不会那么简单，所以为了保持同步，引入了锁机制。
| 2、互斥量与信号量 |
互斥量如其名，同一时间只能被一个线程占有，实现线程间对某种数据结构的互斥访问。试图对一个已经加锁的互斥量加锁，会导致线程阻塞。允许多个线程对同一个互斥量加锁。当对互斥量解锁时，阻塞在该互斥量上的线程会被唤醒，它们竞争对该互斥量加锁，加锁成功的线程将停止阻塞，剩余的加锁失败于是继续阻塞。注意到，谁将竞争成功是无法预料的，这一点就类似于弱信号量。（强信号量把阻塞在信号量上的进程按时间排队，先进先出）
互斥量区别于信号量的地方在于，互斥量只有两种状态，锁定和非锁定。它不像信号量那样可以赋值，甚至可以是负值。共性方面，我所体会到的就一句话，都是用来实现互斥的。
1、生产者消费者问题
该问题要满足：
（1）. 当缓冲区已满时，生产者不会继续向其中添加数据
（2）. 当缓冲区为空时，消费者不会从中移走数据
（3）. 要避免忙等待，睡眠和唤醒操作（原语）
#define N 100 /*缓冲区个数*/
typedef int semaphore; /*信号量是一种特殊的整数类型*/
semaphore mutex = 1; /*互斥信号量：控制对临界区的访问*/
semaphore empty= N; /*空缓冲区的个数*/
semaphore full = 0; /*满缓冲区个数*/
void producer(void)
{
int item;
while(TRUE)
{
item = produce_item()
P(&empty);
P(&mutex);
insert_item(item);
V(&mutex);
V(&full);
}
}
void consumer(void)
{
int item;
while(TRUE)
{
P(&full);
P(&mutex);
item = remove_item()
P(&mutex);
V(&empty);
consume_item(item);
}
}
2、读者写者问题
有读者和写者两组并发进程，共享一个文件，当两个或以上的读进程同时访问共享数据时不会产生副作用，但若某个写进程和其他进程（读进程或写进程）同时访问共享数据时则可能导致数据不一致的错误。因此要求：①允许多个读者可以同时对文件执行读操作；②只允许一个写者往文件中写信息；③任一写者在完成写操作之前不允许其他读者或写者工作；④写者执行写操作前，应让已有的读者和写者全部退出。
| (1)读者优先 |
读进程是优先的，也就是说，当存在读进程时，写操作将被延迟，并且只要有一个读进程活跃，随后而来的读进程都将被允许访问文件。在这种方式下，会导致写进程可能长时间等待，导致存在写进程“饿死”的情况。
int count=0; //用于记录当前的读者数量
semaphore mutex=1; //用于保护更新count变量时的互斥
semaphore rw=1; //用于保证读者和写者互斥地访问文件
writer () { //写者进程
while (1){
P(rw); // 互斥访问共享文件
Writing; //写入
V(rw) ; //释放共享文件
}
}
reader () { // 读者进程
while(1){
P (mutex) ; //互斥访问count变量
if (count==0) //当第一个读进程读共享文件时
P(rw); //阻止写进程写
count++; //读者计数器加1
V (mutex) ; //释放互斥变量count
reading; //读取
P (mutex) ; //互斥访问count变量
count--; //读者计数器减1
if (count==0) //当最后一个读进程读完共享文件
V(rw) ; //允许写进程写
V (mutex) ; //释放互斥变量 count
}
}
| (2)写者优先 |
即当有读进程正在读共享文件时，有写进程请求访问，这时应禁止后续读进程的请求，等待到已在共享文件的读进程执行完毕则立即让写进程执行，只有在无写进程执行的情况下才允许读进程再次运行。为此，增加一个信号量并且在上面的程序中 writer()和reader()函数中各增加一对PV操作，就可以得到写进程优先的解决程序。
int count = 0; //用于记录当前的读者数量
semaphore mutex = 1; //用于保护更新count变量时的互斥
semaphore rw=1; //用于保证读者和写者互斥地访问文件
semaphore w=1; //用于实现“写优先”
writer(){
while(1){
P(w); //在无写进程请求时进入
P(rw); //互斥访问共享文件
writing; //写入
V(rw); // 释放共享文件
V(w) ; //恢复对共享支件的访问
}
}
reader () { //读者进程
while (1){
P (w) ; // 在无写进程请求时进入
P (mutex); // 互斥访问count变量
if (count==0) //当第一个读进程读共享文件时
P(rw); //阻止写进程写
count++; //读者计数器加1
V (mutex) ; //释放互斥变量count
V(w); //恢复对共享文件的访问
reading; //读取
P (mutex) ; //互斥访问count变量
count--; //读者计数器减1
if (count==0) //当最后一个读进程读完共享文件
V(rw); //允许写进程写
V (mutex); //释放互斥变量count
}
}
| 3、死锁 |
死锁就是所有线程都在相互等待释放资源，导致谁也无法继续执行下去。比如哲学家进餐问题，当每个人都同时拿起左边的筷子，那么同时每个人都在等待有人放下获取另一支筷子，这时就构成了死锁。可见竞争资源以及推进进程顺序不当会引发死锁。下面一些简单的规则可以帮助我们避免死锁：
1. 如果有多个锁的话，尽量确保每个线程都是按相同的顺序加锁，按加锁相反的顺序解锁。
(即加锁a->b->c，解锁c->b->a)
2. 防止发生饥饿。即设置一个超时时间，防止一直等待下去。
3. 不要重复请求同一个锁。
4. 设计应力求简单。加锁的方案越复杂就越容易出现死锁。
对于解决哲学家进餐问题有两种解决办法：
| （1）同时只允许一位哲学家就餐 |
semaphore fork[5]={1,1,1,1,1};
semaphore mutex = 1;
void philosopher(int i){
while(TRUE){
think();
P(mutex)
P(fork[i]);
P(fork[(i+1)%N);
V(mutex)
eat();
V(fork[i]);
V(fork[(i+1)%N];
}
| (2)对哲学家顺序编号，要求奇数号哲学家先抓左边的叉子，然后再抓他右边的叉子，而偶数号哲学家刚好相反。 |
semaphore fork[5]={1,1,1,1,1};
void philosopher(int i){
while(TRUE){
think();
if(i%2==1){
P(fork[i]);
P(fork[(i+1)%N);
}else{
P(fork[(i+1)%N]);
P(fork[i]);
}
eat();
V(fork[i]);
V(fork[(i+1)%N];
}
