linux信号的处理--部分源码分析

基于linux master v4.9版本

信号是异步的，

一、信号何时来

信号是异步的，对于一个进程随时都会接收到信号。

二、选择线程（task）来处理

　　那么一个进程接收到信号时，需要选择一个task来处理。如何选择呢？

三、使线程达到能够处理信号的状态

　　设置信号的pending flag。

　　

　　1）对于睡眠线程

　　　　a）处于TASK_INTERRUPTIBLE，唤醒，系统调用返回

     while (dev->current_len == GLOBALFIFO_SIZE) {
         if (filp->f_flags & O_NONBLOCK) {
             ret = -EAGAIN;
             goto out;
         }
         __set_current_state(TASK_INTERRUPTIBLE);

         mutex_unlock(&dev->mutex);

         schedule();
         if (signal_pending(current)) {
             ret = -ERESTARTSYS;
             goto out2;
         }

         mutex_lock(&dev->mutex);
     }

　　　　b）处于TASK_UNINTERRUPTIBLE，

　　　　　　　　i）如果signal是SIGKILL(9)，也会唤醒，返回系统调用

　　　　　　　　ii）如果signal不是SIGKILL(9)，不会唤醒，等task自己从睡眠中醒来，返回系统调用；如果task一直处于深度睡眠中，那么该信号就没办法得到处理

　　　　c）处于TASK_RUNNING（queued/runnable就绪态和运行态，tsk->state = TASK_RUNNING），不需要做进一步处理

四、真正处理信号

　　线程通过系统调用（sys_call）陷入内核态。具体来说，通过int80陷入内核，然后int80的处理函数通过系统调用号来调用sys_call，sys_call返回后会检查该task是否pending信号，有则处理。

　　基于linux0.11版本的分析：https://blog.csdn.net/geekcome/article/details/6398414

基于新代码分析TODO

五、补充

从以上分析得出结论，信号只在系统调用结束，返回用户态前处理。那么一个不调用sys_call的进程就没有办法处理信号了？

实验：最简单的死循环

 int main(){
     while(){}
 }

strace跟踪：为了说明进程的启动，和 一些属性，本文没有删除启动过程产生的系统调用打印；进程启动后，kill -2 pid杀死进程。

 zsh@zsh-vm:~/program/C++$ strace ./signal_while.o
 execve("./signal_while.o", ["./signal_while.o"], [/* 74 vars */]) =
 brk(NULL)                               = 0x8993000
 access("/etc/ld.so.nohwcap", F_OK)      = - ENOENT (No such file or directory)
 mmap2(NULL, , PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -, ) = 0xb7f8c000
 access("/etc/ld.so.preload", R_OK)      = - ENOENT (No such file or directory)
 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) =
 fstat64(, {st_mode=S_IFREG|, st_size=, ...}) =
 mmap2(NULL, , PROT_READ, MAP_PRIVATE, , ) = 0xb7f76000
 close()                                =
 access("/etc/ld.so.nohwcap", F_OK)      = - ENOENT (No such file or directory)
 open("/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) =
 read(, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\207\1\0004\0\0\0"..., ) =
 fstat64(, {st_mode=S_IFREG|, st_size=, ...}) =
 mmap2(NULL, , PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, , ) = 0xb7dc0000
 mmap2(0xb7f70000, , PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, , 0x1af000) = 0xb7f70000
 mmap2(0xb7f73000, , PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -, ) = 0xb7f73000
 close()                                =
 mmap2(NULL, , PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -, ) = 0xb7dbf000
 set_thread_area({entry_number:-, base_addr:0xb7dbf700, limit:, seg_32bit:, contents:, read_exec_only:, limit_in_pages:, seg_not_present:, useable:}) =  (entry_number:)
 mprotect(0xb7f70000, , PROT_READ)   =
 mprotect(0x8049000, , PROT_READ)    =
 mprotect(0xb7fb5000, , PROT_READ)   =
 munmap(0xb7f76000, )               =
 --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---   这是窗口大小改变引起
 --- SIGINT {si_signo=SIGINT, si_code=SI_USER, si_pid=, si_uid=} ---
 +++ killed by SIGINT +++

可以看出信号还是得到了处理。那么就不符合以上的分析结果。再进一步分析，信号的处理时机肯定是统一接口的，那么一个死循环看似永远跑在用户态的进程什么时候会有系统调用呢？答案在进程调度引起了系统调用。普通进程CFS调度类，有233次上下文切换，180次非自愿，53次自愿。 当然这期间还有时钟中断的处理，这属于硬中断，不确定会不会引起信号处理。

 zsh@zsh-vm:~/program/C++$ cat /proc//sched
 signal_while.o (, #threads: )
 -------------------------------------------------------------------
 se.exec_start                                :      83967758.954863
 se.vruntime                                  :        251746.287113
 se.sum_exec_runtime                          :        137316.047183
 se.nr_migrations                             :
 8 nr_switches                                  :                  233
 9 nr_voluntary_switches                        :                   53
10 nr_involuntary_switches                      :                  180
 se.load.weight                               :
 se.avg.load_sum                              :
 se.avg.util_sum                              :
 se.avg.load_avg                              :
 se.avg.util_avg                              :
 se.avg.last_update_time                      :
17 policy                                       :                    0
18 prio                                         :                  120
 clock-delta                                  :                   

五、拓展：1、通过signal no来获取信号处理函数。

　　　　　　task的信号处理函数保存在 task_struct里。

     /* Signal handlers: */
     struct signal_struct        *signal;
     struct sighand_struct        *sighand;

　　　　　signal指向进程信号描述符,不是很明白，与进程组有关，sighand是64个信号处理函数的指针。

 struct sighand_struct {
     atomic_t        count;
     struct k_sigaction    action[_NSIG];
     spinlock_t        siglock;
     wait_queue_head_t    signalfd_wqh;
 };

　　　　当然信号处理函数可以通过signal和sigaction函数设置用户自定义处理函数，不设置即为系统默认处理。linux里面，signal用sigaction实现。

　　　2、驱动层ERESTARTSYS和EINTR的区别

　　　　参考：https://stackoverflow.com/questions/9576604/what-does-erestartsys-used-while-writing-linux-driver

　　　　ERESTARTSYS有两种结果：1）该信号设置了SA_RESTART，会重启系统调用，当然，用户态不感知，但是对于一些系统调用没办法或者很难直接重启系统调用，比如定时器，详见man说明。2）该信号没有设置SA_RESTART，那么会返回到用户态，返回值为-1，并设置errno=EINTR（return −1 and set errno to indicate the error）。

　　　　EINTR只是返回到用户态，返回值为-1，并设置errno=EINTR（return −1 and set errno to indicate the error），上面所述第二种情况。

syscall_get_nr判断是不是从系统调用返回，另外的情况是（硬件）中断和异常（比如page_falut）。

　　　　    只有系统调用睡眠后，被信号唤醒，才会返回ERESTARTSYS或EINTR（具体返回那个视功能决定，比如conncet就不能返回ERESTARTSYS）。如果是不会发生睡眠的系统调用，则不会返回这两个值。那么在信号处理完成后，不会走handle_signal的ERESTARTSYS分支，也就不会返回EINTR错误。所以非阻塞的socket系统调用，比如read、write不会返回EINTR错误。部分代码分析见：https://blog.csdn.net/yusiguyuan/article/details/45669657

　　　　3、系统调用的改变

　　       4、kill命令

DESCRIPTION
The default signal for kill is TERM. Use -l or -L to list available signals. Particularly useful signals include HUP, INT, KILL, STOP, CONT, and . Alternate signals may be specified in
three ways: -, -SIGKILL or -KILL. Negative PID values may be used to choose whole process groups; see the PGID column in ps command output. A PID of - is special; it indicates all pro‐
cesses except the kill process itself and init.

pid>  send_signal对应进程
pid = - send_signal除自己和init进程外的所有进程，
pid =  send_signal本进程组
其他负值 send_signal pid所在进程组
当然是有权限的限制。这里还牵涉到namespace，就不说了。

5、signo < 32 是不能排队的，所以是不可靠信号 0-31共32个是不可靠信号，也叫非实时信号。

  #define SIGRTMIN 32
  static inline int legacy_queue(struct sigpending *signals, int sig)
  {
     return (sig < SIGRTMIN) && sigismember(&signals->signal, sig);
  }

  result = TRACE_SIGNAL_ALREADY_PENDING;
  if (legacy_queue(pending, sig))
       goto ret;

不可靠的来源：

• 进程每次处理信号后，就将对信号的响应设置为默认动作。在某些情况下，将导致对信号的错误处理；因此，用户如果不希望这样的操作，那么就要在信号处理函数结尾再一次调用signal()，重新安装该信号。
• 信号可能丢失，因为不支持排队，pending住信号后，收到同一个信号，那么该信号只能丢弃
  因此，早期unix下的不可靠信号主要指的是进程可能对信号做出错误的反应以及信号可能丢失。目前linux通过sigaction函数已经解决了 signo>SIGRTMIN的两个不可靠来源，< SIGRTMIN为了兼容以前程序没有解决。

6、信号0

http://www.linuxjournal.com/content/monitoring-processes-kill-0

“signal 0″ is kind of like a moral equivalent of “ping”.

Using “kill -0 NNN” in a shell script is a good way to tell if PID “NNN” is alive or not:

signal 0 is just used to check process is exists or not.

题外话：

1、TASK_INTERRUPTIBLE：浅度睡眠

TASK_UNINTERRUPTIBLE：深度睡眠

2、SIGKILL和SIGSTOP信号是不能捕捉和忽略的，即用户态不能对这两个信号设置处理函数和mask，只能执行系统默认行为。

 int do_sigaction(int sig, struct k_sigaction *act, struct k_sigaction *oact)
 {
     if (!valid_signal(sig) || sig <  || (act && sig_kernel_only(sig)))sig_kernel_only --检查对kill 和 stop 行为的非法设置
         return -EINVAL;

     k = &p->sighand->action[sig-];

     spin_lock_irq(&p->sighand->siglock);
     if (oact)
         *oact = *k;

     sigaction_compat_abi(act, oact);

     if (act) {
         sigdelsetmask(&act->sa.sa_mask,
                   sigmask(SIGKILL) | sigmask(SIGSTOP)); --去除对kill 和 stop信号的屏蔽操作

后面发现的资料：http://kernel.meizu.com/linux-signal.html