Linux Signal实现代码分析http://blog.csdn.net/suqin0802/article/details/8093004

 

Linux Signal实现代码分析

分类： Linux LinuxKernel 2013-06-13 01:24  623人阅读  评论(0)  收藏  举报

目录(?)[+]

本文转自：http://blog.csdn.net/walkingman321/article/details/6167435

本文介绍了Linux信号处理的基本流程。关于信号处理的具体细节可以看ULK第三版第11章。

1. 基本数据结构

1.1task_struct中信号相关的域

[cpp]  view plain copy

1. struct signal_struct * signal; // Pointer to the process's signal descriptor  
2.   
3. struct sighand_struct * sighand; // Pointer to the process's signal handler descriptor  
4.   
5. sigset_t blocked; // Mask of blocked signals  
6.   
7. sigset_t real_blocked; // Temporary mask of blocked signals (used by the // rt_sigtimedwait( ) system call)  
8.   
9. struct sigpending pending; // Data structure storing the private pending signals  
10.   
11. unsigned long sas_ss_sp; // Address of alternative signal handler stack  
12.   
13. size_t sas_ss_size; // Size of alternative signal handler stack  
14.   
15. int (*) (void *) notifier; // Pointer to a function used by a device driver to block some // signals of the process  
16.   
17. void * notifier_data; // Pointer to data that might be used by the notifier function // (previous field of table)  
18.   
19. sigset_t * notifier_mask; // Bit mask of signals blocked by a device driver through a // notifier function  

l signal和sighand都是指针，因为同一个进程中所有线程都共享同一个signal和同一个sighand。

l sas_ss_sp和sas_ss_size可以用于定义信号处理函数使用的栈，但不是必须。

1.2sigpending与sigqueue

sigpending代表目前等待处理的信号的集合。

[cpp]  view plain copy

1. struct sigpending {  
2.   
3. struct list_head list; // sigqueue链表  
4.   
5. sigset_t signal; // 待处理的信号集合  
6.   
7. };  

sigpending结构体中，signal域保存所有待处理信号的集合，每个信号占一位。

list域指向sigqueue链表，对于非实时信号（1-31），每个信号在链表中只能拥有一个sigqueue；对于实时信号(32-63)，如果接收到多个相同的信号，每个信号都会在链表中拥有一个sigqueue。

[cpp]  view plain copy

1. struct sigqueue {  
2.   
3. struct list_head list;  
4.   
5. int flags;  
6.   
7. siginfo_t info;  
8.   
9. struct user_struct *user;  
10.   
11. };  

在每个task_struct结构中，有两个sigpending，分别是：

[cpp]  view plain copy

1. struct sigpending pending;  
2.   
3. struct sigpending （struct signal_struct *signal）l->shared_pending;  

之所以有两个sigpending，是由于Linux的线程和进程在内核中都是一个task_struct表示。所以penging域代表线程本身待处理的信号，signal->shared_pending代表线程所属进程的待处理信号。

sigqueue使用非常频繁，所以在内核中专门为其申请了kmem cache。可以在sigqueue_alloc和sigqueue_free中找到其分配、释放的实现代码。

2.信号的发送

2.1普通发送

最常用的发送信号的函数有kill, tkill和tgkill等等。其中tkill已经过时，被tgkill代替。

kill被用来给进程发消息；tgkill被用来给线程发消息。

kill

kill函数最终会调用kill_something_info：

[cpp]  view plain copy

1. struct siginfo info;  
2.   
3. info.si_signo = sig;  
4.   
5. info.si_errno = 0;  
6.   
7. info.si_code = SI_USER;  
8.   
9. info.si_pid = task_tgid_vnr(current);  
10.   
11. info.si_uid = current->uid;  
12.   
13. return kill_something_info(sig, &info, pid);  
14.   
15.   
16. static int kill_something_info(int sig, struct siginfo *info, pid_t pid)  
17.   
18. // 如果pid > 0，发信号给pid指定的进程  
19.   
20. kill_pid_info(sig, info, find_vpid(pid));  
21.   
22. // 否则，如果pid != -1 && pid != 0，发信号给由-pid指定的进程组  
23.   
24. __kill_pgrp_info(sig, info, find_vpid(-pid);  
25.   
26. // 否则，如果pid == 0，发信号给自己所属的进程组  
27.   
28. __kill_pgrp_info(sig, info, task_pgrp(current));  
29.   
30. // 否则（pid == -1），发信号给除自己所属进程之外的其它所有进程  
31.   
32. for_each_process(p) {  
33.   
34. if (task_pid_vnr(p) > 1 && !same_thread_group(p, current))  
35.   
36. group_send_sig_info(sig, info, p);  

在以上所有情况下，最终都会调用send_signal，且改函数最后一个参数为1。

tgkill

tgkill有三个参数，tgid，pid和sig，其中tgid为进程，pid为线程。tgkill最终会调用do_tkill。

[cpp]  view plain copy

1. static int do_tkill(pid_t tgid, pid_t pid, int sig)  
2.   
3. struct siginfo info;  
4.   
5. info.si_signo = sig;  
6.   
7. info.si_errno = 0;  
8.   
9. info.si_code = SI_TKILL;  
10.   
11. info.si_pid = task_tgid_vnr(current);  
12.   
13. info.si_uid = current->uid;  
14.   
15. 。。。  
16.   
17. specific_send_sig_info(sig, &info, p);  
18.   
19. specific_send_sig_info最终会调用send_signal，且最后一个参数为0。  

send_signal

有上面分析可以看出，无论是发信号给进程还是线程，最终都是调用send_signal函数，唯一区别在最后一个参数。

[cpp]  view plain copy

1. <span style="font-size:12px;">int send_signal(int sig, struct siginfo *info, struct task_struct *t, int group)  
2.   
3. struct sigpending *pending;  
4.   
5. /* prepare_signal中,会调用ignore_signal判断信号是否需要被忽略, 
6.  
7. 如果是,则立即返回*/  
8.   
9. if (!prepare_signal(sig, t))  
10.   
11. return 0;  
12.   
13. // 发消息给进程和线程的区别在这里  
14.   
15. pending = group? &t->signal->shared_pending : &t->pending;  
16.   
17. // 如果是非实时信号（<32），且该信号已经在等待队列中，则忽略  
18.   
19. if (legacy_queue(pending, sig))  
20.   
21. return 0;  
22.   
23. // 注意如果传入的info指定为SEND_SIG_FORCED，那么不分配sigqueue  
24.   
25. if (info != SEND_SIG_FORCED)  
26.   
27. // 分配一个sigqueue  
28.   
29. // 将sigqueue挂入sigpending队列  
30.   
31. // 这里要注意除了SEND_SIG_FORCED之外还有几种特殊情况要考虑：  
32.   
33. // SEND_SIG_NOINFO  
34.   
35. // SEND_SIG_PRIV  
36.   
37. // 通知signalfd  
38.   
39. 。。。  
40.   
41. sigaddset(&pending->signal, sig); // 将signal加入pengding->signal位掩码中  
42.   
43. complete_signal(sig, t, group);  
44.   
45. complete_signal用于决定由哪个进程或线程处理该信号  
46.   
47. static void complete_signal(int sig, struct task_struct *p, int group)  
48.   
49. /* 如果指定的任务可以处理，则由该任务处理信号 */  
50.   
51. if (wants_signal(sig, p))  
52.   
53. t = p;  
54.   
55. /* 如果是发给指定线程的信号，或者是单线程进程，因为不满足前一个判断条件，所以直接返回，等待do_signal函数的最终处理 */  
56.   
57. else if (!group || thread_group_empty(p))  
58.   
59. return;  
60.   
61. else // 到这里，只能是发给进程的信号，且该进程是多线程的  
62.   
63. /* 从下面代码可以看出，如果是发给进程的信号，可以唤醒任意一个正在等待该信号的线程 */  
64.   
65. t = signal->curr_target;  
66.   
67. while (!wants_signal(sig, t)) {  
68.   
69. t = next_thread(t);  
70.   
71. if (t == signal->curr_target)  
72.   
73. return;  
74.   
75. }  
76.   
77. signal->curr_target = t;  
78.   
79. // 判断是否是致命信号  
80.   
81. if (sig_fatal(p, sig) &&  
82.   
83. !(signal->flags & (SIGNAL_UNKILLABLE | SIGNAL_GROUP_EXIT)) &&  
84.   
85. !sigismember(&t->real_blocked, sig) &&  
86.   
87. (sig == SIGKILL || !tracehook_consider_fatal_signal(t, sig, SIG_DFL)))  
88.   
89. if (!sig_kernel_coredump(sig))  
90.   
91. 。。。  
92.   
93. // 唤醒需要处理该信号的任务  
94.   
95. signal_wake_up(t, sig == SIGKILL);</span>  

2.2强制发送

强制发送信号可以忽略信号处理的SIG_IGN标记，和stask_struct的blocked域。强制发送可由函数force_sig_specific完成，该函数最终调用force_sig_info。

[cpp]  view plain copy

1. int force_sig_info(int sig, struct siginfo *info, struct task_struct *t)  
2.   
3. 。。。  
4.   
5. // 如果信号处理方式是SIG_IGN，或者task_struct的blocked域包含了该信号，  
6.   
7. // 则解除blocked域对该信号的屏蔽，并设置信号处理方式为SIG_DFL  
8.   
9. // (default处理方式)。  
10.   
11. action = &t->sighand->action[sig-1];  
12.   
13. ignored = action->sa.sa_handler == SIG_IGN;  
14.   
15. blocked = sigismember(&t->blocked, sig);  
16.   
17. if (blocked || ignored) {  
18.   
19. action->sa.sa_handler = SIG_DFL;  
20.   
21. if (blocked) {  
22.   
23. sigdelset(&t->blocked, sig);  
24.   
25. recalc_sigpending_and_wake(t);  
26.   
27. }  
28.   
29. }  
30.   
31. // 如果是default处理方式，清除SIGNAL_UNKILLABLE标记  
32.   
33. if (action->sa.sa_handler == SIG_DFL)  
34.   
35. t->signal->flags &= ~SIGNAL_UNKILLABLE;  
36.   
37. // 发信号给指定线程  
38.   
39. specific_send_sig_info(sig, info, t);  
40.   
41. 。。。  

3.信号的处理

信号的处理在do_signal函数中完成。当系统即将从内核回到用户空间时，会自动调用do_signal函数，此函数与平台相关。

do_signal函数的执行过程简单分析如下：

l 判断有没有信号等待处理

l 如果有，调用do_signal_pending函数

do_signal_pending函数也是平台相关的，简单分析下执行过程：

l 调用get_signal_to_deliver得到要处理的信号。

l 调用handle_signal处理信号

这里有几点需要注意的：

l 如果是SIG_DFL或者SIG_IGN的信号，在get_signal_to_deliver函数中就已经被处理了，不会被返回，返回的都是被登记了自定义处理函数的信号。

l handle_signal并没有真正执行信号处理函数，因为信号处理函数只能在用户空间执行，不能在内核空间执行。内核空间只是设置了用户空间的堆栈，这样当do_signal返回然后切换到用户空间时，就能自动执行信号处理函数了。而执行完之后，还需要再切换到内核空间，再由内核空间重新返回到正常的用户空间程序。

下面再看看get_signal_to_deliver函数的处理过程，对signal的默认处理都在这里完成：

l 调用dequeue_signal得到待处理的信号。

n 这里隐含了信号优先级的概念，因为里面最终调用了ffz函数从signal_pending::signal域得到值最小的那个信号。

n deque_signal会先从task_struct::pending中查找signal，然后再从task_struct::signal->shared_pending中查找signal。也就是说，先处理线程信号，再处理进程信号。从这里也可以看出，多线程进程中，任何一个线程都可能处理发给进程的信号。

l 如果是SIG_IGN和SIG_DEF等情况，直接处理，并回到上一步寻找下一个待处理的信号，没找到则返回0。

l 返回待处理的信号，此信号必定是用户登记了自定义处理函数的。

3.1 sigtimedwait

如果用户任务调用了sigtimedwait，这时处理信号的过程比较特殊。此时，该用户任务会查找当前是否有自己感兴趣的信号正等待处理。

l 如果有penging的信号，则立刻返回。用户任务可以继续执行。

l 如果没有pending的信号，该任务会挂起自身，等待信号的出现。当收到信号之后，在send_signal函数的signal_wake_up中会唤醒该挂起的任务。然后该任务会调用dequeue_signal将信号取出，防止在返回用户空间时信号被do_signal再次处理。

l sigtimedwait一般与sigmask配对使用，这样，能保证我们感兴趣的信号任何时候都不会被do_signal处理。

从以上分析可知，sigtimedwait具有优先权，它能阻塞住自己感兴趣的信号，阻止do_signal函数对这些被阻塞信号的处理。

4.安装信号处理函数

信号处理函数的登记有两种，一种是老式的signal，另一种是sigaction。这两个函数最终都是调用do_sigaction。do_sigaction很简单，主要就是把k_sigaction结构放到task_struct的sighand->action中，当然还有一些小细节，比如对原先是SIG_IGN的信号的处理，等等。

注意信号处理函数是被安装到了进程，而不是线程。一个进程不管有多少线程，对指定信号都只有一个处理函数，这是因为同一进程的所有线程的task_struct结构都指向了同一个sighand结构。所以在do_sigaction中处理SIG_IGN时会有红字标注的这么一段代码：

[cpp]  view plain copy

1. <span style="font-size:12px;">if (sig_handler_ignored(sig_handler(t, sig), sig)) {  
2.   
3. sigemptyset(&mask);  
4.   
5. sigaddset(&mask, sig);  
6.   
7. rm_from_queue_full(&mask, &t->signal->shared_pending);  
8.   
9. do {  
10.   
11. rm_from_queue_full(&mask, &t->pending);  
12.   
13. t = next_thread(t);  
14.   
15. } while (t != current);  
16.   
17. }  
18. </span>  

5.其它

5.1调试信息打印

为方便调试，当收到某些信号时，Linux可以打印出当前CPU的一些信息，方便调试。

这些信号为：

SIGQUIT SIGILL SIGTRAP SIGABRT SIGFPE SIGSEGV

SIGBUS SIGSYS SIGXCPU SIGXFSZ SIGEMT_MASK

打印调试信息的开关可以在引导参数中指定：

__setup("print-fatal-signals=", setup_print_fatal_signals);

从引导参数中解析出print-fatal-signals变量后，打印开关被保存在全局变量print_fatal_signals中。

打印调试信息的函数为print_fatal_signal，里面调用了show_regs函数。

具体的调试信息打印在do_signal->get_signal_to_deliver中：

[cpp]  view plain copy

1. <span style="font-size:12px;">int get_signal_to_deliver(siginfo_t *info, struct k_sigaction *return_ka,  
2.   
3. struct pt_regs *regs, void *cookie)  
4.   
5. 。。。  
6.   
7. if (sig_kernel_coredump(signr)) {  
8.   
9. if (print_fatal_signals)  
10.   
11. print_fatal_signal(regs, info->si_signo);  
12.   
13. do_coredump(info->si_signo, info->si_signo, regs);  
14.   
15. }  
16.   
17. 。。。  
18.   
19. </span>  

5.2信号的通知和屏蔽

Linux的信号处理中有一种机制，可以让线程或进程收到信号时通知某个回调函数，并由回调函数判断是否进入常规的信号处理。这通过task_struct结构中的这三个域完成：

[cpp]  view plain copy

1. int (*notifier)(void *priv); // 收到信号  
2.   
3. void *notifier_data;  
4.   
5. sigset_t *notifier_mask;  
6.   
7. 在__dequeue_signal函数中，有如下代码：  
8.   
9. static int __dequeue_signal(struct sigpending *pending, sigset_t *mask, siginfo_t *info)  
10.   
11. 。。。  
12.   
13. if (current->notifier) {  
14.   
15. if (sigismember(current->notifier_mask, sig)) {  
16.   
17. if (!(current->notifier)(current->notifier_data)) {  
18.   
19. clear_thread_flag(TIF_SIGPENDING);  
20.   
21. return 0;  
22.   
23. }  
24.   
25. }  
26.   
27. }  
28.   
29. 。。。  

即当notifier函数返回0时，屏蔽此信号。

notifier的register和unregister在如下函数中实现：

[cpp]  view plain copy

1. void block_all_signals(int (*notifier)(void *priv), void *priv, sigset_t *mask);  
2.   
3. void unblock_all_signals(void);  

从以上分析还实现函数也可以看出，一个task_struct只能有一个notifier被登记，并且没有防止多个notifier被同时注册的机制。

5.3信号处理函数的栈空间

一般情况下，信号处理函数使用的栈是线程的用户空间栈。但是，信号处理使用的栈也可以单独指定，这就是task_struct中有sas_ss_sp和sas_ss_size这两个域的原因。

信号处理专用栈可以有sys_sigaltstack指定，在handle_signal函数中，会调用get_sigframe。

如果设置了信号专用栈，get_sigframe会使用sas_ss_sp的值代替线程的用户空间栈。