问了群里，才知道这事已经是统信已知Bug。

以下为deepseek的AI翻译：

---

以下是图片中 Linux 内核提交信息（Commit）的中文翻译：

---

author Wentao Guan 2026-09-04 21:44:43 +0800
committer Huacai Chen 2026-09-04 21:44:43 +0800
commit c3f2feace5e4f4b01b68b9f947b19adb4155c32e (patch)
tree a823ab852ce8c6cf866995658c492e0af1a2525
parent 3e1b64bd8cd2bc15c514d90b3dd0a55c53302f3a (diff)
download linux-c3f2feace5e4f4b01b68b9f947b19adb4155c32e.tar.gz

LoongArch: Do not save/restore percpu base register in rethook trampoline

LoongArch：不要在 rethook 跳板中保存/恢复 percpu 基址寄存器

rethook 跳板在入口时将 $r21 (percpu 基址) 保存到其栈帧中，并在退出时恢复它。在此期间，rethook_trampoline_handler() 可能会通过 preempt_enable_notrace() 进行调度。

如果任务迁移到另一个 CPU，栈帧中的 ​r21 保存的是旧 CPU 的 percpu 基址，在新 CPU 上恢复它会污染 r21。直到下一次用户态->内核态的转换修复 $r21 之前，所有 this_cpu_*() 访问（runqueues、RCU 每 CPU 数据、定时器 tick 编程、FPU 所有权）都会命中错误的 CPU percpu 区域。

在 kretprobe 高负载抢占下，这可能破坏调度器和定时器状态：在原子上下文中调度（scheduling-while-atomic）导致内核崩溃、错误的 CPU RCU 警告、在 nohz_balance_exit_idle() 中出现 WARN_ON_ONCE(rq != this_rq())、以及 CPU 停留在空闲循环中且恒定定时器无法重新武装（硬锁死）。在 Loongson-3A6000 上，VFS 路径上启用 kretprobe 并伴随大量文件操作（OS 安装 / unsquashfs）时可以复现此问题。

按照约定，​r21 在内核态始终保存当前 CPU 的 percpu 基址：异常入口处的 SAVE_SOME() 仅在从用户态进入时重新加载它，而 RESTORE_SOME() 仅在返回用户态时恢复它；上下文切换路径永远不会写入它。因此，跳板退出时的活动 r21 已经是正确的，期间没有任何东西可以合法地改变它（内核 C 代码不能写入全局寄存器变量）。同样的缺陷甚至存在于 v6.3 之前的 kretprobe 跳板中；它被延续到替换它的 rethook 中。此处删除保存和恢复。删除恢复足以解决问题，而删除保存是为了保持代码整洁，不需要清除它。

Cc: stable@vger.kernel.org # v6.3+
Fixes: 3f5536860086 ("LoongArch: Add kretprobes support")
Assisted-by: Kimi:Kimi-K3 # 调试与根本原因分析
Signed-off-by: Wentao Guan
Signed-off-by: Huacai Chen

Diffstat

-rw-r--r-- arch/loongarch/kernel/rethook_trampoline.S 2 ⬛

1 个文件发生更改，0 处插入（+），2 处删除（-）

diff --git a/arch/loongarch/kernel/rethook_trampoline.S b/arch/loongarch/kernel/rethook_trampoline.S
index 2e009fbea53f2..1601894446845 100644
--- a/arch/loongarch/kernel/rethook_trampoline.S
+++ b/arch/loongarch/kernel/rethook_trampoline.S
@@ -24,7 +24,6 @@
 	cfi_st	t6, PT_R18
 	cfi_st	t7, PT_R19
 	cfi_st	t8, PT_R20
-	cfi_st	u0, PT_R21
 	cfi_st	fp, PT_R22
 	cfi_st	s0, PT_R23
 	cfi_st	s1, PT_R24
@@ -59,7 +58,6 @@
 	cfi_ld	t6, PT_R18
 	cfi_ld	t7, PT_R19
 	cfi_ld	t8, PT_R20
-	cfi_ld	u0, PT_R21
 	cfi_ld	fp, PT_R22
 	cfi_ld	s0, PT_R23
 	cfi_ld	s1, PT_R24

(页面底部：由 cgit 1.31-kong (git 2.54.0) 于 2026-09-16 15:51:50 +0000 生成)

---

简单点说，LoongArch+preempt+deepin-anything-dkms三个条件集齐导致的。更新依赖带进去了这个文件索引模块+全抢占+高频文件读写触发了这个bug。

6.6.148版的HWE内核已经合入修复补丁，但6.18.36没有。

临时解决办法：

如果开机就卡死，则在grub界面按e编辑启动选项，添加preempt=none关掉抢占。

如图所示，但这只是暂时解决问题，接下来赶紧Ctrl+Ait+T打开终端。

在终端中输入：sudo nano /etc/default/grub

修改grub给内核的启动参数，在这两项的双引号内的这些参数后面加空格“ preempt=voluntary”

然后sudo update-grub

重启后问题暂时解决了。

根本还是要内核并入修复补丁。