test+kernel(sched): align scheduler family syscalls with Linux behavior#962
test+kernel(sched): align scheduler family syscalls with Linux behavior#96204megumi wants to merge 8 commits into
Conversation
![mai-team-app[bot]](https://avatars.githubusercontent.com/u/34859362?s=60&v=4){kind=small}
There was a problem hiding this comment.
PR 概述
本 PR 将 StarryOS 的调度器族系统调用（sched_getscheduler/sched_setscheduler/sched_getparam/sched_setaffinity）与 Linux 行为对齐。核心改动：
- 在
axtask::TaskInner中新增sched_policy（AtomicI32）和sched_priority（AtomicI32）字段，支持每个任务独立的调度策略和优先级存储。 - 实现了
check_sched_permission()权限检查函数，遵循 Linux 的 CAP_SYS_NICE / euid 匹配语义。 sched_setaffinity新增权限检查，sched_setscheduler从空实现改为完整的策略/优先级校验与存储，sched_getscheduler从硬编码SCHED_RR改为读取任务实际策略，sched_getparam从空实现改为读取实际优先级。- 新增
test-sched-family测试用例，覆盖 4 架构（x86_64/aarch64/riscv64/loongarch64），包含正常路径、EINVAL/ESRCH/EFAULT 错误路径和 fork 权限测试。
重复/重叠分析
- 在
origin/dev上搜索了sched_policy、sched_priority、sched_setscheduler等符号：基础分支无对应字段存储和完整实现（sched_getscheduler硬编码返回SCHED_RR，sched_setscheduler/sched_getparam为空操作）。 - 检查了当前所有开放 PR（#963 HAL 重构、#961 RISC-V 动态平台等），未发现与调度器族系统调用重叠的 PR。
- 本 PR 与已有工作无重复或冲突。
实现逻辑分析
整体方向正确，sched_setscheduler 的策略范围校验（SCHED_NORMAL/BATCH/IDLE 要求 prio==0，SCHED_FIFO/RR 要求 prio∈[1,99]）符合 Linux 语义。sched_setaffinity 和 sched_setscheduler 的权限检查也符合 Linux 行为。
但存在一个与 Linux 语义不一致的阻塞性问题，详见行内评论。
测试覆盖
- 测试放置位置
test-suit/starryos/normal/qemu-smp4/test-sched-family正确。 - 4 架构 QEMU 配置齐全，
success_regex和fail_regex设置合理。 - 测试覆盖了
sched_setaffinity/sched_getaffinity、sched_yield、sched_setscheduler/sched_getscheduler、sched_getparam、getpriority的正常路径和错误路径（EINVAL/ESRCH/EFAULT/EPERM）。 - fork 权限测试设计合理，能够覆盖跨进程的权限场景。
结论
存在一个阻塞性问题：sched_getparam 不应包含权限检查。修复后可以重新审查。
Powered by glm-5.1
| Ok(task.sched_policy() as isize) | ||
| } | ||
|
|
||
| pub fn sys_sched_setscheduler(_pid: i32, _policy: i32, _param: *const ()) -> AxResult<isize> { |
There was a problem hiding this comment.
💡 建议：sched_setscheduler 未处理 SCHED_RESET_ON_FORK 标志位
Linux 允许在 policy 参数中 OR 上 SCHED_RESET_ON_FORK（0x40000000）标志。当前实现直接将 _policy as u32 与 SCHED_NORMAL 等常量比较，会导致带该标志的合法调用被误判为 EINVAL。
建议在策略校验前先剥离该标志：
const SCHED_RESET_ON_FORK: u32 = 0x40000000;
let reset_on_fork = (policy & SCHED_RESET_ON_FORK) != 0;
let policy = policy & !SCHED_RESET_ON_FORK;然后在设置任务时存储 reset_on_fork 状态（或在当前阶段先忽略其语义，只做标志剥离以避免 EINVAL 误判）。
There was a problem hiding this comment.
PR 概述
本 PR 将 StarryOS 的调度器族系统调用与 Linux 行为对齐，核心改动：
- 在
axtask::TaskInner中新增sched_policy（AtomicI32）和sched_priority（AtomicI32）字段 - 新增
check_sched_permission()权限检查函数（CAP_SYS_NICE / euid 匹配语义） sched_getscheduler从硬编码SCHED_RR改为读取任务实际策略sched_setscheduler从空实现改为完整的策略/优先级校验与存储，含SCHED_RESET_ON_FORK标志剥离sched_getparam从空实现改为读取实际优先级（无权限检查，符合 Linux 语义）sched_setaffinity新增权限检查- 新增
test-sched-family测试用例，覆盖 4 架构，包含正常路径和 EINVAL/ESRCH/EFAULT/EPERM 错误路径
之前审查问题处理情况
mai-team-app[bot] 在 commit 173cf72b 上的两个阻塞性问题已在最新 commit e1615e10 中解决：
- ✅
sched_getparam已移除check_sched_permission调用，符合 Linux "No special permissions are needed" 语义 - ✅
SCHED_RESET_ON_FORK标志已在sched_setscheduler中正确剥离并接受
实现逻辑分析
- 策略范围校验（SCHED_NORMAL/BATCH/IDLE 要求 prio==0，SCHED_FIFO/RR 要求 prio∈[1,99]）完全符合 Linux
sched_setscheduler(2)语义 ✓ check_sched_permission对 pid==0（自身）直接返回 Ok，对其他进程检查 CAP_SYS_NICE / euid 匹配，符合 Linux 行为 ✓sched_getscheduler和sched_getparam不做权限检查，符合 Linux 语义 ✓SchedParam使用#[repr(C)]+bytemuck::Pod安全转换，正确 ✓sched_policy默认值为 0（即SCHED_NORMAL），sched_priority默认值为 0，正确 ✓
测试覆盖
- 测试放置于
test-suit/starryos/normal/qemu-smp4/test-sched-family，位置正确 ✓ - 4 架构 QEMU 配置齐全，
success_regex/fail_regex设置合理 ✓ - 覆盖正常路径 + EINVAL/ESRCH/EFAULT/EPERM 错误路径 + fork 权限测试 ✓
重复/重叠分析
- 基础分支
origin/dev无sched_policy/sched_priority字段存储和完整实现（sched_getscheduler硬编码SCHED_RR，sched_setscheduler/sched_getparam为空操作） - 当前开放 PR（#963 HAL 重构、#837 kallsyms、#850 等）与调度器族系统调用无重叠
CI 状态
所有 CI 检查均为 skipped（fork 来源 PR 的正常行为），非本 PR 导致。
非阻塞性建议
详见行内评论。sched_getparam 中可用 bytemuck::bytes_of() 替代 unsafe 块，参数命名中的下划线前缀（_pid、_policy、_param）应移除以反映实际使用。_reset_on_fork 目前未存储，sched_getscheduler 不会返回该标志——作为增量实现是合理的，未来完善时需注意。
结论
代码正确性良好，Linux 语义对齐准确，测试覆盖充分，之前的阻塞性问题已全部解决。建议合入。
Powered by glm-5.1
1 participant
No description provided.