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

[Andrea Righi <arighi@nvidia.com>]

On Mon, Sep 14, 2026 at 09:06:40AM +0000, sashiko-bot@kernel.org wrote:
...
> > @@ -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.

This seems legit. The enqueue path may have already updated the rq clock before
reaching sched_resched_curr_lazy(), while the kick path doesn't currently
establish new rq pin context. I think we can avoid the redundant clock update
when the clock is already current and using a pinned rq lock helpers in
kick_one_cpu().

I'll fix this in v3.

-Andrea