Re: [PATCH 01/12] sched/core: Skip migration disabled tasks in proxy execution

[Andrea Righi]

Hi Prateek,

On Thu, Jul 02, 2026 at 11:47:35PM +0530, K Prateek Nayak wrote:
> Hello Andrea,
> 
> On 7/2/2026 10:39 PM, Andrea Righi wrote:
> > Never attempt to migrate migration-disabled tasks or tasks that can only
> > run on a single CPU when switching donor's execution context, preventing
> > task pinning violations.
> > 
> > Signed-off-by: Andrea Righi <arighi@xxxxxxxxxx>
> > ---
> >  kernel/sched/core.c | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index 3cc6fb1d20547..8a3eecc7caf5d 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -6936,6 +6936,20 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
> >  			 */
> >  			if (curr_in_chain)
> >  				return proxy_resched_idle(rq);
> > +			/*
> > +			 * Tasks pinned to a single CPU (per-CPU kthreads via
> > +			 * kthread_bind(), tasks under migrate_disable()) cannot
> > +			 * be moved to @owner_cpu. proxy_migrate_task() uses
> 
> We only move it to donate the vruntime context. It is never actually
> run there.
> 
> > +			 * __set_task_cpu() which would silently violate the
> > +			 * pinning and leave the task to run on a CPU outside
> > +			 * its cpus_ptr once it is unblocked. Deactivate it on
> 
> For the task to run as normal, p->is_blocked needs to be cleared. It is
> only done in the wakeup path (and sometimes in find_proxy_task() if
> the task is rq->curr) which ensures all the affinity / migrate disable
> bits get fixed when the task gets to actually run.
> 
> Where / how is this being violated?
> 
> > +			 * this CPU; the owner running elsewhere will wake @p
> > +			 * back up when the mutex becomes available.
> > +			 */
> > +			if (p->nr_cpus_allowed == 1 || is_migration_disabled(p)) {
> > +				__clear_task_blocked_on(p, NULL);
> > +				goto deactivate;
> > +			}
> 
> Proxy depends on the ability to migrate the donor context to owner's
> CPU without actually running the task. The task is superficially on
> the CPU only to give it's runtime share to the lock owner. Feels like
> you are tripping a shortcoming in ext core if this is a problem.

Agree with all of the above. As I mention in the other email, I had this in the
previous version, because I was hitting migration-disabled errors. Maybe they
were related to an issue in the sched_ext core, I'll remove this and repeat my
tests.

Thanks,
-Andrea