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

[Juri Lelli <juri.lelli@redhat.com>]

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