Re: [PATCH bpf-next] sched_ext: Reset task fields on exit of an SCX_TASK_READY task

[Tejun Heo]

Hello, Rahad.

On Fri, Nov 06, 2026 at 08:28:18PM +0600, Rahad Bhuiya wrote:
> However, in __scx_disable_and_exit_task(), an exiting task in state
> SCX_TASK_READY (e.g., a forked task that was initialized via
> ops.init_task() but never enabled under an ext_sched_class before exiting,
> or a disabled task) currently breaks out of the state switch without
> calling scx_reset_task_fields().

Neither example has anything to reset. A forked task which exits while
READY goes through sched_ext_dead() and is freed. A task disabled from
ENABLED is already reset: both callers of scx_disable_task(), the
ENABLED case here and switched_from_scx(), call scx_reset_task_fields()
right after it.

A READY task is on a sched but outside the ext class. RT and DL tasks
are always in that state, and so are non-SCHED_EXT tasks under a partial
switch. The sched's BPF code can still write such a task's dsq_vtime and
slice, and because the READY exit doesn't reset them, they carry over
when the task moves to another sched.

For example, an RT task in a cgroup owned by sub-sched A gets its
dsq_vtime set by A's ops.cgroup_move(), as scx_flatcg does. If the task
is then moved to a cgroup owned by sub-sched B and later switches to
SCHED_NORMAL, B's ops.enable() sees the dsq_vtime from A's clock.

Can you rewrite the description around that case?

> Fixes: a298fd5f4ee8 ("sched_ext: Fix use-after-free of a NONE rescuee leaving its sched while running")

a298fd5f4ee8 didn't change the READY case. It was a bare break before
and after. The gap goes back to 5771e79e461e ("sched_ext: Reset
dsq_vtime and slice when a task leaves SCX"), which put the reset only
on the ENABLED path, so that'd be the one to point at if the patch keeps
a Fixes tag.

sched_ext patches go through the sched_ext tree, not bpf-next. Can you
repost with the above updated?

Thanks.

--
tejun