Re: [PATCH 1/2] sched_ext: Add lazy preemption support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Calling update_rq_clock(rq) inside scx_resched_curr_lazy() triggers a WARN_DOUBLE_CLOCK warning because the runqueue clock has already been updated in the calling contexts.
--

commit 6fc03e981449ffc8b39d02362a88e51ad755b27e
Author: Andrea Righi <arighi@nvidia.com>

sched_ext: Add lazy preemption support

The fair scheduling class can request lazy rescheduling, deferring an
in-kernel scheduling boundary until returning to user space or until the
next scheduler tick. sched_ext only exposes immediate preemption,
preventing BPF schedulers from making the same trade-off.

> diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> index 11114a6daf387..6d39f715196dc 100644
> --- a/kernel/sched/ext/ext.c
> +++ b/kernel/sched/ext/ext.c

[ ... ]

> @@ -1515,6 +1515,23 @@ static void call_task_dequeue(struct scx_sched *sch, struct rq *rq,
>  	p->scx.flags &= ~SCX_TASK_IN_CUSTODY;
>  }
>  
> +/*
> + * A task with an infinite slice may be running with its tick stopped. Lazy
> + * rescheduling doesn't send an IPI, so restore the tick dependency first to
> + * guarantee that the lazy request is promoted by a real scheduler tick.
> + */
> +static void scx_resched_curr_lazy(struct rq *rq)
> +{
> +	if (rq->scx.flags & SCX_RQ_CAN_STOP_TICK) {
> +		rq->scx.flags &= ~SCX_RQ_CAN_STOP_TICK;
> +		update_rq_clock(rq);
> +		update_other_load_avgs(rq);

[Severity: Medium]
Does this trigger a SCHED_WARN_ON(rq->clock_update_flags & RQCF_UPDATED)
double-clock update warning?

It looks like update_rq_clock() can be called from paths where the clock
has already been updated or the rq lock was taken without pinning.

For example, during a task enqueue, enqueue_task() updates the clock and
sets RQCF_UPDATED. The call chain then reaches rq_owned_post_enq() ->
scx_resched_curr_lazy(), calling update_rq_clock() while RQCF_UPDATED is
still set.

It also appears reachable via kick_one_cpu(), which acquires the runqueue
lock using raw_spin_rq_lock_irqsave() rather than rq_pin_lock(). This means
RQCF_UPDATED is not cleared from the previous lock hold, and calling
scx_resched_curr_lazy() here updates the clock without a valid pin context.

> +		sched_update_tick_dependency(rq);
> +	}
> +
> +	resched_curr_lazy(rq);
> +}
> +

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914084955.1798562-1-arighi@nvidia.com?part=1