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

K Prateek Nayak
2026-04-03T13:43:45Z

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