Re: [PATCH v23 7/9] sched: Have try_to_wake_up() handle return-migration for PROXY_WAKING case

[K Prateek Nayak <kprateek.nayak@amd.com>]

Hello John,

On 11/20/2025 6:35 AM, John Stultz wrote:
>> Sounds like block_task() would be better than deactivate_task() above
>> in that case. Anything that is waiting on the task's state change takes
>> the pi_lock afaik and the wakeup is always done with pi_lock held so
>> blocking the task shouldn't cause any problems based on my reading.
> 
> So earlier I did try using block_task() but it always seemed to run
> into crashes, which I assumed was because other cpus were picking the
> task up as it wasn't on_rq (any references to a task after
> block_task() in other situations often runs into this trouble).
> 
> But your point about the pi_lock being held is a good one, so I will
> tinker and think a bit more on this.

So if you hadn't used DEQUEUE_SPECIAL previously with block_task(),
there is a case where:

> @@ -3784,6 +3834,8 @@ static int ttwu_runnable(struct task_struct *p, int wake_flags)
>  		update_rq_clock(rq);
>  		if (p->se.sched_delayed)
>  			enqueue_task(rq, p, ENQUEUE_NOCLOCK | ENQUEUE_DELAYED);
> +		if (proxy_needs_return(rq, p))
> +			goto out;

Task turns delayed here but the delayed condition is handled
before proxy_needs_return(). Perhaps you can try reordering
them?

Since we avoid calling block_task() on blocked donors, I
don't think they can be delayed until we actually call
block_task().

I might be missing other subtleties but this is one case
I could think of.

>  		if (!task_on_cpu(rq, p)) {
>  			/*
>  			 * When on_rq && !on_cpu the task is preempted, see if

-- 
Thanks and Regards,
Prateek