fix(starry-task): publish SIGKILL before ptrace release

[ZR233]

问题

当处于初始 ptrace stop 的 tracee 在另一 CPU 上收到 SIGKILL 时，原实现会先清除 stop 并唤醒 tracee，再把 SIGKILL 写入进程信号队列。被唤醒的 tracee 因而可能先执行用户态的 _exit(0)，使父进程观察到正常退出而不是 SIGKILL 终止。

该问题可在 riscv64 四核 QEMU 中复现：固定 tracer 与 tracee 到不同 CPU，未修复基线会将第 38 轮的 SIGKILL 报为 status=0。

修改

• 先发布进程信号，再中断被选中的信号接收线程；若 ptrace stop 所在线程不同，也显式中断该线程，使其在信号已经可见后退出 stop。
• 将 job-control 的 stop 释放放在信号发布之后，并用小的同步边界固定这一顺序。
• 从初始 ptrace stop 返回后、执行第一条用户指令前重新检查待处理信号，避免未屏蔽的 SIGKILL 被竞态的 _exit(0) 覆盖。
• 扩展 riscv64 QEMU 回归：在不同 CPU 上重复 64 次 ptrace stop + SIGKILL，验证每轮都得到信号终止状态。

这是从 #1775 的重构链中抽出的独立修复；不引入新的公开接口或平台能力。

验证

• 排序单测：先以旧顺序运行得到确定性失败，修正后通过。
• cargo xtask starry test qemu --arch riscv64 -c qemu/test-proc-status-tracerpid
• cargo xtask clippy --package starry-kernel（25/25 配置通过）

[mai-team-app]

本次修改修复了初始 ptrace stop 中 SIGKILL 的发布/唤醒竞态：先将信号发布到进程 pending 队列，再中断信号接收线程及停住的 tracee；从停止态返回到用户态前再次扫描 pending 信号，避免 tracee 抢先执行 _exit(0)。改动局限于 Starry task/signal 内部实现与现有 qemu/system/test-proc-status-tracerpid 回归用例，不新增公开接口；book/guideline/feature-development.md 不适用，code-quality.md 与 Starry syscall 语义准则已按 ptrace、kill、waitpid 的间接用户可见路径核对。

实现检查：ProcessSignalManager::send_signal 在取得候选线程前已把 pending 状态以 Release 语义发布；本改动随后才 interrupt 停止的 tracee，并在首次用户指令前通过 check_signals 消费待处理的不可屏蔽 SIGKILL。测试放在现有 grouped system CMake 自动发现、构建和安装路径中；riscv64 QEMU 配置为 4 CPU，新增 64 轮跨 CPU ptrace stop + SIGKILL 断言，每轮均要求 WIFSIGNALED(SIGKILL)，能够捕获原先错误的正常退出状态。

验证：组织当前头 99121799a9d1572446366e503fae1b41fac76043 的 CI 已成功（38 success、40 expected skipped、3 cancelled 的互斥/陈旧矩阵）；其中 Starry riscv64 QEMU 路径由此次 task/test-suit 变更触发。按“CI 已通过无需重复本地全量测试”的约定，未重复 QEMU；本地执行 cargo fmt --all -- --check、git diff --check 和新增 C 源的 cc -std=gnu11 -Wall -Wextra -Werror -fsyntax-only 均通过。PR 描述所列 cargo xtask clippy --package starry-kernel 与 riscv64 QEMU 验证亦已由作者完成。无 [patch.crates-io] 变更。

历史 review/issue 评论为空。重复与重叠检查：base 不含此 SIGKILL 发布顺序修复；相关开放 PR #1775 是更大范围的 task 重构链，本 PR 明确从其抽取独立修复，当前改动不依赖其落地。未发现待解决的阻塞问题或测试缺口；无需额外指派领域 reviewer。

Powered by gpt-5.6-terra