Linux scheduler sync

sched-ext discussion

Re: [PATCH] sched_ext: Delete sub-scheduler kobjects before releasing scx_enable_mutex

讨论分析 success2026/09/02 14:201 封邮件
0/1 已展开

LLM 分析

sched_ext：子调度器 kobject 释放顺序 PATCH 撤回

系列概况

  • 标题：Re: [PATCH] sched_ext: Delete sub-scheduler kobjects before releasing scx_enable_mutex
  • 作者：Qiurong Fang <fangqiurong@kylinos.cn>
  • 版本：无（仅一封回复邮件，非新版本 PATCH）
  • 规模：1 封回复
  • 修改文件：无（PATCH已被作者撤回）
  • 代码统计：无
  • Message-ID：20260902062007.446314-1-fangqiurong@kylinos.cn
  • 完整性：完整，单封回复，附带对上游解释的回应与撤回声明

补丁目的

原 PATCH 的方向是：在 sched_ext 卸载/退出路径上，把子调度器（sub-scheduler）的 kobject 删除动作放到 scx_enable_mutex 释放之前。意图是确保在锁还持有期间，sysfs/引用计数相关的对象就已经清理完毕，避免锁释放后仍有路径访问悬空 kobject。该 PATCH 已被作者撤回。

关键实现

本封邮件不携带代码改动，仅表达两点：

  1. 接受 maintainer Tejun 的解释，确认当前释放顺序是预期行为；
  2. 正式撤回原 PATCH，不再继续推。
+------------------+ +------------------------+      +-------------------+
| Qiurong Fang     |      | [PATCH]                |      | Tejun Heo         |
| sub-sched kobj | ---> | sched_ext: delete      | ---> | reviewer / |
| release order    |      | sub-sched kobjects |      | sched_ext         |
| proposal         |      | before                 |      | maintainer        |
+------------------+      | scx_enable_mutex       |      +-------------------+
                          +------------------------+               |
                                                                    v +-------------------+
 | "Expected |
                                                          |  behavior, no     |
                                                          |  change needed." |
                                                          +-------------------+
                                                                    |
                                                                    v
 +------------------------+      +-------------------+
                          | (this reply)           | <--- | Qiurong Fang      |
                          | withdraw the patch     |      | understands & |
                          +------------------------+      | withdraws         |
                                                          +-------------------+

类比

像酒店退房：客人提议"先交还房卡、再退押金"，前台解释"行业惯例是先退押金、再收回房卡"，客人于是撤回自己的请求。代码本身没动，但流程边界更清晰。

Highlight：风险与注意点

  • 撤回 ≠ 问题不存在：作者最初观察到 PATCH，说明他在某个 trace/场景下怀疑过释放顺序，需要留意他的复现条件是否后续会被别人重新遇到。
  • scx_enable_mutex 的"持有/释放边界"是 sched_ext 的高敏感点：后续若有人重写 enable/disable 路径，应保留禁用/卸载路径的并发测试覆盖。
  • 单封邮件无法判断上游是否已经在某个提交里调整过类似顺序；阅读近期 sched_ext commits 时，需要专门关注 scx_exit / scx_enable_mutex 周围函数。
  • 撤回动作对外是"无变更"，但 lore 上仍然留有原始 PATCH 链接，索引系统可能出现"补丁已发→已撤"的混合状态，搜索时要核对最新状态。

一句话总结

作者在收到 Tejun 关于 sched_ext 当前释放顺序就是预期行为的解释后，正式撤回此前关于"在释放 scx_enable_mutex 之前删除子调度器 kobject"的 PATCH。