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

[sashiko-bot@kernel.org]

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@163.com>

sched: Dispatch task ticks for donor and execution classes

Proxy execution can run a task from one scheduling class on behalf of a donor
from another. This patch updates sched_class::task_tick() to drop the task
argument, using a common dispatcher to call the donor class first and, if
needed, the execution class second.

Link: https://lore.kernel.org/r/20260908104407.GD687043@noisy.programming.kicks-ass.net

> diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> index 51de1d8b72a1e..70815bef52960 100644
> --- a/kernel/sched/ext/ext.c
> +++ b/kernel/sched/ext/ext.c
[ ... ]
> @@ -3789,9 +3789,15 @@ void scx_tick(struct rq *rq)
>  	update_other_load_avgs(rq);
>  }
>  
> -static void task_tick_scx(struct rq *rq, struct task_struct *curr, int queued)
> +static void task_tick_scx(struct rq *rq, int queued)
>  {
> -	struct scx_sched *sch = scx_task_sched(curr);
> +	struct task_struct *curr = rq->donor;
> +	struct scx_sched *sch;
> +
> +	if (curr->sched_class != &ext_sched_class)
> +		return;
> +
> +	sch = scx_task_sched(curr);
>  
>  	update_curr_scx(rq);

[Severity: High]
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 · https://sashiko.dev/#/patchset/20260909092901.2989564-1-sh_def@163.com?part=1