Re: [PATCH v25 9/9] sched: Handle blocked-waiter migration (and return migration)

Juri Lelli
2026-03-18T10:16:38Z

On 18/03/26 12:26, K Prateek Nayak wrote:
> Hello Juri,
>
> On 3/18/2026 12:05 PM, Juri Lelli wrote:
> >> + deactivate_task(rq, p, DEQUEUE_NOCLOCK);
> >> + proxy_set_task_cpu(p, target_cpu);
> >> +
> >> + /*
> >> + * We have to zap callbacks before unlocking the rq
> >> + * as another CPU may jump in and call sched_balance_rq
> >> + * which can trip the warning in rq_pin_lock() if we
> >> + * leave callbacks set.
> >> + */
> >> + zap_balance_callbacks(rq);
> >> + rq_unpin_lock(rq, rf);
> >> + raw_spin_rq_unlock(rq);
> >> +
> >> + attach_one_task(target_rq, p);
> >
> > We release rq lock between deactivate and attach (and we don't hold
> > neither wait_lock nor blocked_lock as they are out of scope at this
> > point). Can't something like the following happen?
> >
> > - Task A: blocked on mutex M, queued on CPU 0
> > - Task B: owns mutex M, running on CPU 1
> >
> > CPU 0 (migrating A→CPU 1) CPU 1 (B finishes critical section)
> > ------------------------- ------------------------------------
> > find_proxy_task(donor=A):
> > owner = B, owner_cpu = 1
> > action = MIGRATE
> > // guard releases wait_lock
> >
> > proxy_migrate_task(A, cpu=1):
> > deactivate_task(rq0, A)
> > → A->on_rq = 0
>
> This sets TASK_ON_RQ_MIGRATING
> before dequeuing.

Right you are, I missed this!

Sorry for the noise and thanks for the quick reply.

Best,
Juri