Re: [PATCH v4 1/5] sched: Dispatch task ticks for donor and execution classes

[Andrea Righi]

Hi Hui,

On Wed, Sep 09, 2026 at 07:42:51PM +0900, Hui Su wrote:
> On Tue, Sep 09, 2026, Sashiko AI review wrote:
> > Thank you for your contribution! Sashiko AI review found 1 potential
> > issue(s) to consider:
> >
> > - ## [High] Infinite timeslice and preemption bypass during SCX proxy
> >   execution due to a mismatch between slice decrement (execution context)
> >   and slice checking (scheduling context).
> >
> > commit ff57ff4a11692a1b0d98a6cd57257eb58a1bd864
> > Author: Hui Su <sh_def@xxxxxxx>
> >
> > Does this cause an infinite timeslice for SCX tasks during proxy execution?
> >
> > When an SCX task acts as a donor in proxy execution, task_tick_scx() sets
> > curr to rq->donor. However, update_curr_scx() applies the slice decrement
> > to the execution context (rq->curr):
> >
> > static void update_curr_scx(struct rq *rq)
> > {
> >         struct task_struct *curr = rq->curr;
> >         ...
> >         if (curr->scx.slice != SCX_SLICE_INF)
> >                 curr->scx.slice -= min_t(u64, curr->scx.slice, delta_exec);
> >         ...
> > }
> >
> > Later in task_tick_scx(), the slice check is performed against the donor
> > task which was never decremented:
> >
> >         if (!curr->scx.slice)
> >                 resched_curr(rq);
> >
> > Since the donor's slice doesn't decrease, it will never hit zero, meaning
> > resched_curr(rq) is bypassed indefinitely.
> >
> > Additionally, if the proxy task is SCX but the donor is not,
> > task_tick_scx() returns early here because the donor is not an SCX task,
> > skipping the SCX tick processing completely. Should the slice management
> > be explicitly tied to the execution context rather than the donor?
> >
> > --
> > Sashiko AI review
> 
> Thanks for the report.
> 
> This configuration is currently unreachable. CONFIG_SCHED_PROXY_EXEC
> depends on !SCHED_CLASS_EXT, so sched_ext and proxy execution cannot be
> enabled together.
> 
> When CONFIG_SCHED_CLASS_EXT=y, proxy execution is disabled and rq->donor
> and rq->curr alias the same task. Therefore task_tick_scx() using
> rq->donor and update_curr_scx() using rq->curr still operate on the same
> task, and the slice decrement and check cannot diverge.
> 
> The sched_ext change in this patch only adapts it to the new task_tick()
> interface for the currently supported configuration.
> 
> If sched_ext and proxy execution are made compatible in the future, the
> SCX donor/execution-context ownership will need to be handled as part of
> that integration.

They should be compatible soon:
https://lore.kernel.org/r/20260831134338.1531664-1-arighi@xxxxxxxxxx/

It'd be good to handle SCX donor/execution context ownership in this serie as
well, or we can coordinate to figure out the required changes.

I haven't looked at the whole patch series yet (will do soon), this is JFYI. :)

Thanks,
-Andrea