Linux kernel 分析之十一：信号通信

信号是进程之间通信的一种方式。它包括3部分操作：
1.设置信号处理函数。系统调用signal。内核调用sys_signal()，设置当前进程对某信号的处理函数。
2.发送信号.系统调用kill。内核调用sys_kill()。向目标进程发送信号。3.接收并处理信号。目标进程调用do_signal()处理信号。
从用户态的角度看，目标进程在执行用户态的代码时突然“中断”，转而去执行对应的信号处理函数（同样在用户态）。等到信号处理函数执行完后，又从原来被中断的代码开始执行。
如何达到这样的效果呢？由前面的几种内核的伪装现场的手段，我们可以猜出它这次使用的手段。比如，要让目标进程执行信号处理函数，在内核态中当然不可能直接调用，但是可以通过设置pt_regs中的eip来达到这种效果。但是，要使目标进程在执行完信号处理函数后，又恢复到被中断的现场继续执行，那得花些技巧。不过，不外乎设置堆栈。这一次还包括了用户态堆栈。由于恢复的任务比较艰巨，系统干脆提供了一个系统调用sigreturn 。
既然内核希望用户在执行完信号处理函数后，调用sigreturn。接下去的思路就比较简单了。就是先把用户态的eip设置为signal_handler（通过修改pt_regs中的eip来实现），然后把堆栈中的返回地址改成调用sigreturn的一段代码的入口（当然原来的返回地址也还是要保存的）并且把相关参数“压入”用户态堆栈。
这样，在源进程发送信号后不久，目标进程被调度到，然后执行到do_signal。对信号一一作处理。调用顺序：
do_signal()->handle_signal()->setup_rt_frame()用来设置用户态堆栈。
我们看看这个函数做了些啥？
447         frame = get_sigframe(ka, regs, sizeof(*frame));
struct rt_sigframe __user *frame是内核在用户态的堆栈上新分配的一个数据结构。

011 struct rt_sigframe

012 {

013         char *pretcode;

014         int sig;
015         struct siginfo *pinfo;

016         void *puc;
017         struct siginfo info;

018         struct ucontext uc;

019         struct _fpstate fpstate;

020         char retcode[8];

021 };

图示：高地址
--------------用户进程原堆栈底部--------------用户进程原堆栈顶部
frame->retcode
frame底部
frame->pretcode返回地址：从signal handler返回后跳转的地址--------------frame顶部：用户进程新堆栈顶部
低地址
里面保存了大量用户态进程的上下文信息。尤其是 pretcode，现在位于用户进程的新堆栈的顶部。
接下去开始设置frame
458         err |= __put_user(usig, &frame->sig);
459         err |= __put_user(&frame->info, &frame->pinfo);

460         err |= __put_user(&frame->uc, &frame->puc);

461         err |= copy_siginfo_to_user(&frame->info, info);

462         if (err)
463                 goto give_sigsegv;

464 

465         /* Create the ucontext.  */
466         err |= __put_user(0, &frame->uc.uc_flags);

467         err |= __put_user(0, &frame->uc.uc_link);
468         err |= __put_user(current->sas_ss_sp, &frame->uc.uc_stack.ss_sp);

469         err |= __put_user(sas_ss_flags(regs->esp),

470                           &frame->uc.uc_stack.ss_flags);

471         err |= __put_user(current->sas_ss_size, &frame->uc.uc_stack.ss_size);
472         err |= setup_sigcontext(&frame->uc.uc_mcontext, &frame->fpstate,

473                                 regs, set->sig[0]);
474         err |= __copy_to_user(&frame->uc.uc_sigmask, set, sizeof(*set));
当用户进程根据pt_regs中设置好的eip执行signal handler。执行完毕后就会把frame->pretcode作为返回地址。（这一点2.6.13的内核与2.4的不同，后者是把指针指向retcode,其实仍然是调用sigreturn的代码。）
478         /* Set up to return from userspace.  */

479         restorer = &__kernel_rt_sigreturn;

480         if (ka->sa.sa_flags & SA_RESTORER)

481                 restorer = ka->sa.sa_restorer;

482         err |= __put_user(restorer, &frame->pretcode);
这里的&__kernel_rt_sigreturn就是内核设置的负责信号处理“善后”工作的代码入口。

定义在arch/i386/kernel/vsyscall-sigreturn.Snm /usr/src/linux/vmlinux|grep _kernel_rt_sigreturn
得，它的值是_kernel_rt_sigreturn&__kernel_rt_sigreturn的值应该是内核态的。
问题来了。

frame->pretcode是作为进程在用户态执行的代码（事实上，从执行signal handler开始，进程一直处于用户态）。它怎么能访问内核态的代码呢？

这不是会段错误么？
这里涉及到PIII中用sysenter来代替系统调用的int 0x80的问题。大概就是内核允许一部分代码给用户态进程访问。例如：
cat /proc/$pid/maps可以看到：
ffffe000-fffff000 ---p 00000000 00:00 0          [vdso]ldd 一个应用程序也可以看到：linux-gate.so.1 =>  (0xffffe000)
在arch/i386/kernel/中可以看到两个文件：vsyscall-sysenter.sovsyscall-int80.so
也就是说，__kernel_rt_sigreturn这段代码是链接在两个动态链接文件中。而不是vmlinux这个内核文件中。
具体是如何做到的，就不展开说了。
总之，在执行完signal handler后，进程将跳转到__kernel_rt_sigreturn。

021 __kernel_sigreturn:

022 .LSTART_sigreturn:
023         popl %eax               /* XXX does this mean it needs unwind info? */
024         movl $__NR_sigreturn, %eax
025         int $0x80
实际上调用的是sigreturn系统调用。该系统调用会根据frame里的信息，把堆栈恢复到处理信号之前的状态。所以这段代码是不返回的。然后，用户进程就像什么事也没发生，继续照常运行。
这里，内核通过设置用户态堆栈的手段，达到了打断用户态进程的运行，转而调用signal handler的目的。手段不可谓不高明。