On Mon, Mar 23, 2026 at 02:18:32PM +0800, zhidao su wrote:
> Sub-sched error paths have historically been fragile: a cgroup
> double-put bug and an uninitialized return value were both found in
> the abort path but not caught by automated tests because only the
> happy path was covered.
>
> Add three tests targeting specific failure scenarios:
>
> 1. sub_sched_parent_reject: Tests the sub_attach rejection path.
> A parent scheduler returning -EPERM forces the kernel to execute
> the abort path (ext.c abort label), which must correctly clean up
> partially-initialized tasks and SCX_TASK_SUB_INIT flags. This is
> the path where commit 0c66b0da0064 ("sched_ext: Fix cgroup
> double-put on sub-sched abort path") and commit e36bc38ebfac
> ("sched_ext: Fix uninitialized ret in scx_alloc_and_add_sched()")
> occurred.
>
> 2. sub_sched_nesting: Tests cascading disable through a 3-level
> scheduler hierarchy (root -> level1 -> level2). When schedulers
> are detached in reverse order, drain_descendants() must recursively
> wait for all children to complete their disable sequence without
> deadlock or resource leaks.
>
> 3. sub_sched_race: Tests concurrent race between parent disable and
> child enable. A background thread destroys the parent link while
> the main thread attaches the child, exercising synchronization
> between scx_sub_enable_workfn() and the parent disable path.
>
> All three tests create cgroups under /sys/fs/cgroup/ and are verified
> to pass on a kernel with sub-sched support enabled.
Let's hold off on sub-sched tests for now. It's a bit too early.
Thanks.
--
tejun
