Re: [PATCH v3 05/10] sched/fair: Force a local resched on yield_to() so the buddy is picked

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Double clock update triggers WARN_DOUBLE_CLOCK on the local runqueue in yield_to_task_fair().
--

commit fb0067f31069bbf43450f383db09dc5489957b42
Author: Wanpeng Li <wanpengli@tencent.com>

sched/fair: Force a local resched on yield_to() so the buddy is picked

This commit modifies yield_to_task_fair() to force a local reschedule when
applying lag credit, cancelling slice protection and calling resched_curr()
on the local runqueue. The forced preemption is rate-limited to at most
once per 6ms per rq.

> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 48f65a4f19230..e9c5265cf0fa9 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
[ ... ]
> @@ -9485,6 +9485,83 @@ static void yield_task_fair(struct rq *rq)
[ ... ]
> +static void yield_to_local_force_resched(struct rq *rq)
> +{
> +	struct sched_entity *yse = &rq->donor->se;
> +
> +	yield_task_fair(rq);
[ ... ]
> @@ -9504,21 +9581,22 @@ static bool yield_to_task_fair(struct rq *rq, struct task_struct *p)
[ ... ]
> -	if (rq != p_rq)
> +	update_rq_clock(rq);
> +	if (p_rq != rq)
>  		update_rq_clock(p_rq);
>  
>  	for_each_sched_entity(se) {
[ ... ]
> -	yield_task_fair(rq);
> +	/*
> +	 * Force the local CPU to reschedule so the credited buddy can be
> +	 * selected instead of the protected yielder;
> +	 * yield_to_local_force_resched() also does the leaf forfeit.
> +	 */
> +	yield_to_local_force_resched(rq);

[Severity: Medium]
Will this sequence trigger WARN_DOUBLE_CLOCK on the local runqueue?

The patch comments note this redundant update is only warned about under
the default-off WARN_DOUBLE_CLOCK.

However, update_rq_clock(rq) is called in yield_to_task_fair() setting
RQCF_UPDATED. Then yield_to_local_force_resched(rq) calls yield_task_fair()
which calls update_rq_clock(rq) a second time.

Since the flag isn't cleared between these calls, this will trigger:
WARN_ON_ONCE(rq->clock_update_flags & RQCF_UPDATED)

Is it okay to knowingly leave this double clock update, or could it cause
spurious stack traces for developers actively debugging scheduler clock
issues?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260612013355.59231-1-kernellwp@gmail.com?part=5