Re: [PATCH v26 00/10] Simple Donor Migration for Proxy Execution

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

Hello Peter,

On 4/3/2026 4:58 PM, Peter Zijlstra wrote:
> On Fri, Apr 03, 2026 at 03:55:22PM +0530, K Prateek Nayak wrote:
>>>> @@ -4256,6 +4277,15 @@ int try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
>>>>  		 */
>>>>  		smp_cond_load_acquire(&p->on_cpu, !VAL);
>>>>  
>>>> +		/*
>>>> +		 * We never clear the blocked_on relation on proxy_deactivate.
>>>> +		 * If we don't clear it here, we have TASK_RUNNING + p->blocked_on
>>>> +		 * when waking up. Since this is a fully blocked, off CPU task
>>>> +		 * waking up, it should be safe to clear the blocked_on relation.
>>>> +		 */
>>>> +		if (task_is_blocked(p))
>>>> +			clear_task_blocked_on(p, NULL);
>>>> +
>>>
>>> Aah, yes! This is when find_proxy_task() hits deactivate() for us and we
>>> skip ttwu_runnable(). We still need to clear ->blocked_on.
> 
> I wonder, should we have proxy_deactivate() do this instead?

That is one way to tackle that, yes!

> 
>>>
>>>>  		cpu = select_task_rq(p, p->wake_cpu, &wake_flags);
>>>>  		if (task_cpu(p) != cpu) {
>>>>  			if (p->in_iowait) {
>>>> @@ -6977,6 +7007,10 @@ static void __sched notrace __schedule(int sched_mode)
>>>>  		switch_count = &prev->nvcsw;
>>>>  	}
>>>>  
>>>> +	/* See: https://github.com/kudureranganath/linux/commit/0d6a01bb19db39f045d6f0f5fb4d196500091637 */
>>>> +	if (!prev_state && task_is_blocked(prev))
>>>> +		clear_task_blocked_on(prev, NULL);
>>>> +
>>>
>>> This one confuses me, ttwu() should never results in ->blocked_on being
>>> set.
>>
>> This is from the signal_pending_state() in try_to_block_task() putting
>> prev to TASK_RUNNING while still having p->blocked_on.
> 
> Ooh, I misread that. I saw that set_task_blocked_on_waking(, NULL) in
> there and though it would clear. Damn, sometimes reading is so very
> hard...
> 
> Anyhow, with my changes on, try_to_block_task() is only ever called from
> __schedule() on current. This means this could in fact be
> clear_task_blocked_on(), right?

Yes, that should work too but there is also the case you mentioned on
the parallel thread - if ttwu() doesn't see p->blocked_on, it won't
clear it and if ttwu_runnable() wins we can simply go into
__schedule() with TASK_RUNNING + p->blocked_on with no guarantee that
same task will be picked again. Then the task gets preempted and stays
in an illegal state.

Clearing of ->blocked_on in schedule also safeguards against that race:

o Scenario 1: ttwu_runnable() wins

  CPU0				CPU1

  LOCK				ACQUIRE
  [W] ->blocked_on = lock       [R] ->__state
  [W] ->__state = state;        RMB
                                [R] ->blocked_on
                                [W] ->__state = RUNNING

           /* Synchronized by rq_lock */

  MB
  [R] if (!->__state &&
  [R]     ->blocked_on)
  [W]   ->blocked_on = NULL; /* Safeguard */


o Scenario 2: __schedule() wins

  CPU0				CPU1

  LOCK				ACQUIRE
  [W] ->blocked_on = lock       [R] ->__state
  [W] ->__state = state;

           /* Synchronized by rq_lock */
  MB
  [W]  __block_task()

                                MB
                                /* Full wakeup. */
                                [R] if (->blocked_on)
                                [W]   ->blocked_on = NULL

-- 
Thanks and Regards,
Prateek