Re: [PATCH 09/17] sched_ext: Fix ops.running/stopping() pairing for proxy-exec donors

Hello,

On Sun, Aug 16, 2026 at 07:35:07PM +0200, Andrea Righi wrote:
> +static void set_next_task_scx(struct rq *rq, struct task_struct *p, bool first)
> +{
>  	if (p->scx.flags & SCX_TASK_QUEUED) {
>  		/*
>  		 * Core-sched might decide to execute @p before it is
> @@ -3024,9 +3037,14 @@ static void set_next_task_scx(struct rq *rq, struct task_struct *p, bool first)
>  
>  	p->se.exec_start = rq_clock_task(rq);
>  
> -	/* see dequeue_task_scx() on why we skip when !QUEUED */
> -	if (SCX_HAS_OP(sch, running) && (p->scx.flags & SCX_TASK_QUEUED))
> -		SCX_CALL_OP_TASK(sch, running, rq, p);
> +	/*
> +	 * See dequeue_task_scx() for why we skip when !QUEUED. On a normal
> +	 * scheduling transition, defer starting a blocked donor's session until
> +	 * proxy resolution succeeds. A restore follows an already resolved
> +	 * scheduling context and can start the session immediately.
> +	 */
> +	if ((p->scx.flags & SCX_TASK_QUEUED) && (!p->is_blocked || !first))
> +		scx_start_task_running(rq, p);

nit: can we do !(p->is_blocked && first) instead? I think that matches
what's being expressed better.

Also, can you expand the comment? I find it a bit difficult to follow. So,
when we're actually switching to a donor, we skip running transition because
proxy resolution might give us nothing or it may have to run on a differnet
CPU and so on, so we do running transition after proxy resolution is done.
For SAVE/RESTORE, this doesn't apply as they're always matched regardless of
donor state. Is that the right reading?

>  	clr_task_runnable(p, true);
>  
> @@ -3072,6 +3090,13 @@ static void set_next_task_scx(struct rq *rq, struct task_struct *p, bool first)
>  
>  void scx_proxy_donor_start(struct rq *rq)
>  {
> +	struct task_struct *donor = rq->donor;
> +
> +	lockdep_assert_rq_held(rq);
> +
> +	if (donor->sched_class == &ext_sched_class &&
> +	    (donor->scx.flags & SCX_TASK_QUEUED))

another nit: no need for line break.

> +		scx_start_task_running(rq, donor);
>  }

Thanks.

-- 
tejun