Linux进程间通讯
Linux进程间通讯(二)信号(下)
上一篇文章讲解了信号的注册,这篇文件讲解信号的发送和信号的处理
一、信号的发送
我们可以直接通过 kill 或者 sigqueu 系统调用,给某个进程发送信号,也可以通过 tkill 或者 tgkill 给某个线程发送信号。虽然方法很多,但是最终调用的都是 do_send_sig_info 函数
do_send_sig_info 函数会调用 send_signal,进而调用 __send_signal
__send_signal 的定义如下
static int __send_signal(int sig, struct siginfo *info, struct task_struct *t,
int group, int from_ancestor_ns)
{
struct sigpending *pending;
struct sigqueue *q;
int override_rlimit;
int ret = 0, result;
......
pending = group ? &t->signal->shared_pending : &t->pending;
......
if (legacy_queue(pending, sig))
goto ret;
if (sig < SIGRTMIN)
override_rlimit = (is_si_special(info) || info->si_code >= 0);
else
override_rlimit = 0;
q = __sigqueue_alloc(sig, t, GFP_ATOMIC | __GFP_NOTRACK_FALSE_POSITIVE,
override_rlimit);
if (q) {
list_add_tail(&q->list, &pending->list);
switch ((unsigned long) info) {
case (unsigned long) SEND_SIG_NOINFO:
q->info.si_signo = sig;
q->info.si_errno = 0;
q->info.si_code = SI_USER;
q->info.si_pid = task_tgid_nr_ns(current,
task_active_pid_ns(t));
q->info.si_uid = from_kuid_munged(current_user_ns(), current_uid());
break;
case (unsigned long) SEND_SIG_PRIV:
q->info.si_signo = sig;
q->info.si_errno = 0;
q->info.si_code = SI_KERNEL;
q->info.si_pid = 0;
q->info.si_uid = 0;
break;
default:
copy_siginfo(&q->info, info);
if (from_ancestor_ns)
q->info.si_pid = 0;
break;
}
userns_fixup_signal_uid(&q->info, t);
}
......
out_set:
signalfd_notify(t, sig);
sigaddset(&pending->signal, sig);
complete_signal(sig, t, group);
ret:
return ret;
}
进程的 task_struct 中,有两个 sigpending,表示进程收到的信号。一个表示整个进程收到的信号,所有线程共享,叫做 shared_pending;一个表示线程收到的信号,叫做 pending
__send_signal 首先决定使用哪个 sigpending,决定是发送给整个进程的,还是发送给某个线程的
struct sigpending 里面有两个成员,其定义如下
struct sigpending {
struct list_head list;
sigset_t signal;
};
- sigset_t:是一个bitmap,它表示接收的哪些信号
- list_head :是一个链表,它也表示接收的哪些信号
这两个有什么区别呢?我们接着往下看 __send_signal 的代码来寻找答案
接下来调用的是 legacy_queue,如果满足条件的话就退出,满足什么条件呢?看一下 legacy_queue 的定义
static inline int legacy_queue(struct sigpending *signals, int sig)
{
return (sig < SIGRTMIN) && sigismember(&signals->signal, sig);
}
#define SIGRTMIN 32
#define SIGRTMAX _NSIG
#define _NSIG 64
当信号小于 SIGRTMIN(即32)的时,并且信号当前在集合中,那么就退出
这样会导致什么现象呢?会导致信号的丢失,如果我们频繁地发送小于32的信号给同一个进程,可能在某一次发送的过程中,由于上一次的发送,信号还存在与 signal 中,此时该信号就会被丢失,因此我们将小于32的信号称为不可靠信号
如果信号大于32会怎么样呢?
我们继续看 __send_signal,接下来会分配一个 struct sigqueue 对象,然后将其加到 struct sigpending 的链表中,由于使用链表来保存发送给进程的信号,所以一般情况下,信号不会丢失,我们称大于 32 的信号为可靠信号
最后调用 complete_signal,其定义如下
static void complete_signal(int sig, struct task_struct *p, int group)
{
struct signal_struct *signal = p->signal;
struct task_struct *t;
/*
* Now find a thread we can wake up to take the signal off the queue.
*
* If the main thread wants the signal, it gets first crack.
* Probably the least surprising to the average bear.
*/
if (wants_signal(sig, p))
t = p;
else if (!group || thread_group_empty(p))
/*
* There is just one thread and it does not need to be woken.
* It will dequeue unblocked signals before it runs again.
*/
return;
else {
/*
* Otherwise try to find a suitable thread.
*/
t = signal->curr_target;
while (!wants_signal(sig, t)) {
t = next_thread(t);
if (t == signal->curr_target)
return;
}
signal->curr_target = t;
}
......
/*
* The signal is already in the shared-pending queue.
* Tell the chosen thread to wake up and dequeue it.
*/
signal_wake_up(t, sig == SIGKILL);
return;
}
这里面的逻辑是,赶紧找一个线程来处理信号
首先找到一个进程或线程的 task_struct,然后调用 signal_wake_up 来试图唤醒它
signal_wake_up 会调用 signal_wake_up_state,其定义如下
void signal_wake_up_state(struct task_struct *t, unsigned int state)
{
set_tsk_thread_flag(t, TIF_SIGPENDING);
if (!wake_up_state(t, state | TASK_INTERRUPTIBLE))
kick_process(t);
}
signal_wake_up_state 做了两件事
- 第一件事是给这个 task_struct 设置 TIF_SIGPENDING。这一点向进程调度相似,当要发生系统调度的时候,并不是直接将现在运行的进程换下来,而是设置 TIF_SIGPENDING 标志,然后在系统调用结束或中断返回的时候,再调用 schedule 来调度进程。信号也是类似的,先设置一个 TIF_SIGPENDING 标志,表示这个进程有信号需要处理,然后再系统调用结束或者中断处理结束,从内核态返回用户态的时候,再来处理信号
- 第二件事是试图唤醒这个进程。wake_up_state 会设置该进程的状态为 TASK_RUNNING,然后放到运行队列中,随着时钟不断地滴答,迟早会被调用
至此信号的发送过程已经结束了,接下来看如何处理它
二、信号的处理
从系统调用或者中断返回的时候,最终都会调用 exit_to_usermode_loop,其定义如下
static void exit_to_usermode_loop(struct pt_regs *regs, u32 cached_flags)
{
while (true) {
......
if (cached_flags & _TIF_NEED_RESCHED)
schedule();
......
/* deal with pending signal delivery */
if (cached_flags & _TIF_SIGPENDING)
do_signal(regs);
......
if (!(cached_flags & EXIT_TO_USERMODE_LOOP_FLAGS))
break;
}
}
首先,会判断 _TIF_NEED_RESCHED 是否需要调度进程,如果需要就调度进程,然后会从 schedule 函数中返回
然后再通过 _TIF_SIGPENDING 判断是否需要处理信号,如果需要处理信号,那么就调用 do_signal 处理,下面看看它的定义
void do_signal(struct pt_regs *regs)
{
struct ksignal ksig;
if (get_signal(&ksig)) {
/* Whee! Actually deliver the signal. */
handle_signal(&ksig, regs);
return;
}
/* Did we come from a system call? */
if (syscall_get_nr(current, regs) >= 0) {
/* Restart the system call - no handlers present */
switch (syscall_get_error(current, regs)) {
case -ERESTARTNOHAND:
case -ERESTARTSYS:
case -ERESTARTNOINTR:
regs->ax = regs->orig_ax;
regs->ip -= 2;
break;
case -ERESTART_RESTARTBLOCK:
regs->ax = get_nr_restart_syscall(regs);
regs->ip -= 2;
break;
}
}
restore_saved_sigmask();
}
do_signal 会调用 handle_signal函数,按说,信号的处理就是调用信号的处理函数,但是这事并没有那么简单,因为信号的处理函数是在用户空间的,内核态下面是不能直接调用的,那可怎么办呢?
我们先回忆系统调用的过程。这个进程当时进行系统调用,在进入内核态的时候,会将该进程在用户态下面运行到某一行代码 Line A 保存进程在内核的 pt_regs 里面。在系统调用放回的时候,本应该从 pt_regs 中拿出 Line A,接着继续执行下去。但是现在要处理信号,我们不能直接返回 Line A,而应该返回信号处理函数的起始地址
handle_signal 的定义如下
static void
handle_signal(struct ksignal *ksig, struct pt_regs *regs)
{
bool stepping, failed;
......
/* Are we from a system call? */
if (syscall_get_nr(current, regs) >= 0) {
/* If so, check system call restarting.. */
switch (syscall_get_error(current, regs)) {
case -ERESTART_RESTARTBLOCK:
case -ERESTARTNOHAND:
regs->ax = -EINTR;
break;
case -ERESTARTSYS:
if (!(ksig->ka.sa.sa_flags & SA_RESTART)) {
regs->ax = -EINTR;
break;
}
/* fallthrough */
case -ERESTARTNOINTR:
regs->ax = regs->orig_ax;
regs->ip -= 2;
break;
}
}
......
failed = (setup_rt_frame(ksig, regs) < 0);
......
signal_setup_done(failed, ksig, stepping);
}
所以这个时候,我们就需要来修改 pt_regs 了。这个时候,我们要看是否从系统调用中返回。如果是从系统调用中返回,还需要区分我们从系统调用中正常返回,还是在一个非运行状态的系统调用中,由于信号的唤醒而从系统调用中返回
下面我们来分析一个场景,假设从网卡读取数据,会发生系统调用,然后最后会调用到下面这个函数
static ssize_t tap_do_read(struct tap_queue *q,
struct iov_iter *to,
int noblock, struct sk_buff *skb)
{
......
while (1) {
if (!noblock)
prepare_to_wait(sk_sleep(&q->sk), &wait,
TASK_INTERRUPTIBLE);
/* Read frames from the queue */
skb = skb_array_consume(&q->skb_array);
if (skb)
break;
if (noblock) {
ret = -EAGAIN;
break;
}
if (signal_pending(current)) {
ret = -ERESTARTSYS;
break;
}
/* Nothing to read, let's sleep */
schedule();
}
......
}
如果网卡没有数据,那么就调用 schedule,进入睡眠状态
当该进程被唤醒的时候,会从 schedule 中返回,然后重新执行循环,这个时候因为还没有数据,所以接着往下运行。当遇到 signal_pending 的时候,检测到 _TIF_SIGPENDING 被设置,这说明,这个系统调用调用在没有完成的情况下,被信号中断了,此时直接返回 -ERESTARTSYS
然后准备返回到用户空间,会调用到 exit_to_usermode_loop,最终又调用到了 handle_signal
然后在 handle_signal 中发现错误 -ERESTARTSYS 的时候,知道这是一个未完成的系统调用,设置错误码 -EINTR
接下来就开始折腾 pt_regs 了,主要通过调用 setup_rt_frame -> __set_rt_frame,其定义如下
static int __setup_rt_frame(int sig, struct ksignal *ksig,
sigset_t *set, struct pt_regs *regs)
{
struct rt_sigframe __user *frame;
void __user *fp = NULL;
int err = 0;
frame = get_sigframe(&ksig->ka, regs, sizeof(struct rt_sigframe), &fp);
......
put_user_try {
......
/* Set up to return from userspace. If provided, use a stub
already in userspace. */
/* x86-64 should always use SA_RESTORER. */
if (ksig->ka.sa.sa_flags & SA_RESTORER) {
put_user_ex(ksig->ka.sa.sa_restorer, &frame->pretcode);
}
} put_user_catch(err);
err |= setup_sigcontext(&frame->uc.uc_mcontext, fp, regs, set->sig[0]);
err |= __copy_to_user(&frame->uc.uc_sigmask, set, sizeof(*set));
/* Set up registers for signal handler */
regs->di = sig;
/* In case the signal handler was declared without prototypes */
regs->ax = 0;
regs->si = (unsigned long)&frame->info;
regs->dx = (unsigned long)&frame->uc;
regs->ip = (unsigned long) ksig->ka.sa.sa_handler;
regs->sp = (unsigned long)frame;
regs->cs = __USER_CS;
......
return 0;
}
frame 的类型是 rt_sigframe,是栈帧的意思
get_sigframe 会通过 pt_regs 的 sp 变量,获取用户栈,然后在用户栈中塞入一个栈帧,将 pt_regs中的值保存在这个结构中,然后又返回栈顶位置
然后又重新设置了 pt_regs,将 pt_regs 的 sp 指针设置为 frame,ip 设置为信号处理函数的地址,再修改 pt_regs 中其它的值。通过这个操作,就是将原来的 pt_regs 塞入用户栈中,然后栈指针往下生长,指令指针指向信号处理函数的地址
这样子,当系统调用返回的时候,执行的就是信号处理函数了
那当信号处理函数运行往后,又怎么回到进程原来的运行代码处呢?
其实栈中存放的不仅仅只有原先 pt_regs 的内容,还有 sa_restorer 函数的地址,当信号处理函数返回的时候,就会从栈中弹出这个函数地址,然后跳转到这个函数运行,sa_restorer 函数具体是什么呢?
它其实是一个系统调用,对应的定义如下
asmlinkage long sys_rt_sigreturn(void)
{
struct pt_regs *regs = current_pt_regs();
struct rt_sigframe __user *frame;
sigset_t set;
unsigned long uc_flags;
frame = (struct rt_sigframe __user *)(regs->sp - sizeof(long));
if (__copy_from_user(&set, &frame->uc.uc_sigmask, sizeof(set)))
goto badframe;
if (__get_user(uc_flags, &frame->uc.uc_flags))
goto badframe;
set_current_blocked(&set);
if (restore_sigcontext(regs, &frame->uc.uc_mcontext, uc_flags))
goto badframe;
......
return regs->ax;
......
}
这里,会从用户进程的栈中,把 pt_regs 的信息恢复,之后系统调用返回就会返回到进程原理来运行地方了
对于进程来说,还误以为从上一次系统调用中返回,并不知道这其中的一系列操作
三、总结
信号的发送和处理是一个非常复杂的过程,下面来总结一下
- 1.假设进程A发生系统调用进入内核
- 2.按照系统调用的处理,会将用户栈的信息保存到 pt_regs 中,也即记住了原来用户态运行到了 Line A 的位置
- 3.当在内核中读取数据的时候,发现没有数据读,此时会调用 schedule 发生调度
- 4.当发送信号给进程A,会找到进程A的 task_struct ,将信号加入信号集合或者信号链表中,然后唤醒进程A
- 5.当系统调用返回或者中断返回的时候,会切换到进程A,进程A被唤醒,然后判断是否又数据可读,发现没有,然后发现是被信号唤醒,于是返回一个错误
- 6.在系统调用返回时,会进程信号的处理
- 7.会将 pt_regs 还有 sa_restorer 的函数地址保存到用户栈中
- 8.修改 pt_regs,栈指针向下生长,设置指令指针为信号处理函数地址,然后系统调用返回,返回后会执行信号处理函数
- 9.当信号处理函数执行完之后,会从栈中弹处 sa_restorer 的函数地址,跳转到 sa_restorer 运行
- 10.sa_restorer 是一个系统调用,它会从栈中获取进程原来 pt_regs 的值,然后恢复 pt_regs,系统调用返回后,就回到了进程原先运行的地方