panic函数执行时内核立即停止调度，禁用抢占、关闭调度器，其他CPU被通知停机，定时器与软中断冻结，printk仍可输出；默认不重启，仅无限循环，是否重启取决于panic=参数值。
panic 函数执行时内核立即停止调度
当 panic() 被调用，内核不再尝试恢复或切换进程——它直接禁用抢占（preemption）、关闭调度器（sched_clock 停摆），并让当前 CPU 进入不可中断状态。其他 CPU 会收到 smp_send_stop() 信号，要么自我挂起（panic_smp_self_stop()），要么等待主 CPU 完成锁同步后一并停机。
- 所有定时器、软中断、工作队列全部冻结，
printk()仍可输出（因已提升控制台日志等级console_verbose()） - 若配置了
CONFIG_DEbug_BUGVERBOSE=y，错误位置的文件名和行号会随 panic 信息一起打出 - 注意：如果此时正连着
kgdb或kdump，流程会被劫持——前者交控制权给调试器，后者启动内存转储
系统不会“自动重启”，除非显式配置了 panic_timeout
默认情况下，panic() 执行完打印后，会进入无限循环（for(;;) cpu_relax();），屏幕卡死、键盘灯闪烁、无响应——这不是重启，是真·死循环。是否重启，取决于内核参数 panic= 的值：
-
panic=0（默认）：永不重启，死等人工干预 -
panic=10：等待 10 秒后自动触发machine_restart() - 该值可通过
/proc/sys/kernel/panic运行时修改，但仅对后续 panic 生效
关键资源清理被跳过，只做最小化安全收尾
与用户态程序退出不同，panic 不走常规清理路径：exit()、close()、sync() 全部跳过。唯一保留的是原子级操作：
-
bust_spinlocks(1)：强制释放所有自旋锁，避免死锁掩盖真实问题 -
crash_kexec()（若启用 kdump）：在内存被破坏前，快速跳转到备用内核捕获vmcore -
kmsg_dump()：把最后缓冲区里的日志刷到持久存储（如 pstore、ramoops） - 磁盘写缓存（page cache、buffer cache）大概率丢失，所以 panic 后看到的文件系统损坏往往不是 panic 引起的，而是 panic 前就已发生
你看到的“aieee”或“Oops”不是 panic 本身，而是前置信号
Kernel panic - not syncing: ... 是最终宣告；而屏幕上先出现的 Aieee! 或长段 Unable to handle kernel NULL pointer dereference，其实是 oops —— 它属于“可恢复异常”，只有在中断上下文、持有 spinlock 或配置了 panic_on_oops=1 时，才会升级为 panic。
- 检查是否启用了
panic_on_oops：运行cat /proc/sys/kernel/panic_on_oops，值为 1 表示任何 oops 都会变 panic - 很多驱动 bug 在测试环境表现为 oops，在生产环境因配置差异变成 panic，这点极易误判根源
- 别只盯着最后一行 panic 文字，往上翻 200 行——真正的故障点几乎总在 oops 栈回溯里
真正棘手的从来不是 panic 这个动作，而是它像一面镜子：照出你没留意的硬件隐患、没验证的模块兼容性、或早已腐烂却侥幸存活的驱动逻辑。一旦 panic 日志里反复出现同一设备名或函数名，别急着重启，先查 lsmod 和 dmesg -T | grep -A5 -B5 "xxx"。