Linux 信号机制--最终章－信号处理
一、信号处理的核心问题
进程收到信号后，不会立即处理，而是在“合适的时候”才处理。这个“合适的时候”就是：
进程从内核态返回用户态之前
为什么是这个时候？因为：
信号处理函数是用户代码，必须在用户态执行
内核不能直接执行用户代码（否则就跳过了权限检查）
所以必须等进程准备返回用户态时，内核“顺便”检查一下有没有信号要处理
二、三张表的关系
| 表 | 作用 | 可修改性 |
|---|---|---|
| block | 记录哪些信号被屏蔽 | 可用sigprocmask修改 |
| pending | 记录收到了哪些信号 | 只能读取，不能直接修改（由内核自动置位/清零） |
| handler | 记录每个信号的处理方式 | 可用signal修改 |
为什么 pending 表不能直接修改？
因为 pending 是内核的“待办事项清单”，由内核根据事件自动填写。如果用户能随意修改，就可以伪造信号，破坏系统安全。但是我们也有修改的方式，那就是我们前面讲的５种产生信号的方式
三、特殊信号
| 信号 | 编号 | 特性 |
|---|---|---|
| SIGKILL | 9 | 不可被捕捉、不可被屏蔽、不可被忽略 |
| SIGSTOP | 19 | 不可被捕捉、不可被屏蔽、不可被忽略 |
这两个是“管理员信号”，必须执行默认动作。
四、信号处理时机详解
4.1 正常流程
用户态进程执行 ↓ 调用系统调用（或发生中断/异常） ↓ 进入内核态，执行内核代码 ↓ 系统调用完成，准备返回用户态 ↓ 内核检查当前进程的 pending 表 ├─ 如果没有信号 → 直接返回用户态 └─ 如果有信号 → 进入 do_signal()可以理解成：
4.2 do_signal() 的处理逻辑
void do_signal() { for (每个 pending 中的信号) { if (信号被 block) continue; switch (handler[signo]) { case SIG_IGN: // 忽略：只清 pending 位 clear_pending(signo); break; case SIG_DFL: // 默认动作：可能是终止、停止等 default_action(signo); break; default: // 自定义捕捉：最复杂的情况 setup_user_handler(signo); break; } } }五、自定义捕捉的详细过程
5.1 为什么要复杂？
因为：
handler 是用户代码，必须在用户态执行
但 handler 执行完后，还要回到内核，再由内核返回用户态的原代码
这需要在用户栈上“模拟”一次函数调用
5.2 具体步骤
假设进程正在执行main函数，调用read系统调用时收到信号：
用户栈布局（简化）： ┌──────────────┐ 高地址 │ main 的栈帧 │ ├──────────────┤ │ read 系统调用 │ ← 当前执行点 └──────────────┘ 低地址第 1 步：进入内核
进程执行
read→ 陷入内核内核完成
read工作，准备返回
第 2 步：发现有信号要处理
内核检查 pending，发现 SIGUSR1 有自定义 handler
第 3 步：内核在用户栈上构造“假栈帧”
新的用户栈布局： ┌──────────────┐ 高地址 │ main 的栈帧 │ ├──────────────┤ │ 原返回地址 │ ← 保存的 main 返回点 ├──────────────┤ │ handler 参数 │ ← signo ├──────────────┤ │ handler 返回地址│ ← 指向 __sigreturn ├──────────────┤ │ handler 栈帧 │ └──────────────┘ 低地址第 4 步：修改程序计数器
内核修改进程的上下文，让 CPU 返回用户态时直接执行 handler
栈顶指向 handler 的栈帧
第 5 步：执行 handler
CPU 在用户态执行 handler 代码
handler 执行完毕，执行
ret指令因为栈上放的是
__sigreturn的地址，所以 CPU 跳转到__sigreturn
第 6 步：__sigreturn 重新进入内核
__sigreturn是一个特殊的系统调用它再次陷入内核，告诉内核“信号处理完了，恢复原进程”
第 7 步：内核恢复原上下文
内核把之前保存的 main 上下文恢复
返回用户态，main 继续执行
六、为什么不能让内核直接执行 handler？
绝对不能。
如果内核直接执行用户代码：
用户可以在 handler 里写
rm -rf /内核以最高权限执行 → 系统被破坏
跳过了所有权限检查
所以必须：
内核准备环境
CPU 切回用户态执行 handler
handler 执行完再切回内核清理
七、中断与信号的类比
| 特性 | 硬件中断 | 信号 |
|---|---|---|
| 触发源 | 外部设备 | 内核/其他进程 |
| 编号 | 中断号 | 信号编号 |
| 处理表 | 中断向量表（IDT） | handler 表 |
| 处理函数 | 内核提供 | 用户提供 |
| 执行环境 | 内核态 | 用户态 |
本质区别：
中断是硬件机制，用于 CPU 与外设交互
信号是软件机制，用于进程间通信和异常通知
可以把信号理解为软件模拟的中断。
八、中断控制器的作用
外设1 ──┐ 外设2 ──┼── 中断控制器 ── CPU 外设3 ──┘为什么需要中断控制器？
CPU 的引脚很宝贵，不能每个外设都直接连
中断控制器负责：
收集多个外设的中断
给每个中断分配唯一的中断号
按优先级向 CPU 报告
九、总结流程
硬件中断/异常/系统调用 ↓ 进程进入内核态 ↓ 执行内核代码 ↓ 准备返回用户态 ↓ 检查 pending 表 ├─ 无信号 → 直接返回用户态 └─ 有信号 → do_signal() ├─ 默认/忽略 → 直接处理，返回用户态 └─ 自定义 → 构造用户栈，修改上下文 ↓ 返回用户态执行 handler ↓ handler 执行完 → __sigreturn 重新进入内核 ↓ 内核恢复原上下文 ↓ 返回用户态，原代码继续