Re: [PATCH v2] sched: Restart hrtick after same-task repicks

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Restarting the SCHED_DEADLINE hrtick on same-task repick uses a stale `dl_se->runtime`, pushing the timer expiration into the future and allowing bandwidth overruns.
--

commit fe44140b6abb0653f45d8368ffe6e56a2831b43c
Author: Shubhang Kaushik (Ampere) <sh@gentwo.org>
sched: Restart hrtick after same-task repicks

This commit introduces explicit hrtick restarts for same-task repicks in both
fair and deadline scheduling classes. It adds a new SNT_REPICK type to bypass
normal transition work while still rearming the timer.

Link: https://lore.kernel.org/r/20260813-sched-fair-hrtick-restart-v1-1-4230d1e18fbb@gentwo.org

> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 0663c00c41c04..6c17563f42a1d 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
[ ... ]
> -static void set_next_task_dl(struct rq *rq, struct task_struct *p, bool first)
> +static void set_next_task_dl(struct rq *rq, struct task_struct *p, enum snt_e type)
>  {
>  	struct sched_dl_entity *dl_se = &p->dl;
>  	struct dl_rq *dl_rq = &rq->dl;
>  
> +	if (type == SNT_REPICK)
> +		goto repick;
> +
>  	p->se.exec_start = rq_clock_task(rq);
[ ... ]
>  	deadline_queue_push_tasks(rq);
>  
> +repick:
>  	if (hrtick_enabled_dl(rq))
>  		start_hrtick_dl(rq, &p->dl);
>  }

[Severity: High]
Does this code use a stale dl_se->runtime to arm the hrtick?

When a wake-up or other non-tick preemption check sets TIF_NEED_RESCHED
on a running SCHED_DEADLINE task without calling update_curr_dl(),
__schedule() might repick the same task (e.g., if the woken task was migrated
away before picking).

If that happens, put_prev_set_next_task() takes the SNT_REPICK path, which
skips put_prev_task():

kernel/sched/sched.h:put_prev_set_next_task() {
    ...
	if (next == prev) {
		next->sched_class->set_next_task(rq, next, SNT_REPICK);
		return;
	}
    ...
}

Because put_prev_task() is skipped, its embedded update_curr_dl() call is
also skipped. As a result, dl_se->runtime is not decremented for the time
executed since the last update.

When start_hrtick_dl() is then invoked from the repick label above, the new
hrtick is erroneously scheduled using the un-updated runtime.

Can this allow SCHED_DEADLINE tasks to exceed their configured bandwidth bounds
and starve other tasks?

> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index e656c7059bf86..defcf7fd023fa 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
[ ... ]
> @@ -2802,11 +2808,13 @@ static inline void put_prev_set_next_task(struct rq *rq,
>  
>  	__put_prev_set_next_dl_server(rq, prev, next);
>  
> -	if (next == prev)
> +	if (next == prev) {
> +		next->sched_class->set_next_task(rq, next, SNT_REPICK);
>  		return;
> +	}
>  
>  	prev->sched_class->put_prev_task(rq, prev, next);
> -	next->sched_class->set_next_task(rq, next, true);
> +	next->sched_class->set_next_task(rq, next, SNT_PICK);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260911-sched-fair-hrtick-restart-v2-1-0d34db26ecd1@gentwo.org?part=1