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

[Andrea Righi]

Hi Peter,

On Thu, Jul 02, 2026 at 08:21:18PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 02, 2026 at 07:09:17PM +0200, 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
> > +			 * __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
> > +			 * this CPU; the owner running elsewhere will wake @p
> > +			 * back up when the mutex becomes available.
> > +			 */
> 
> No, this is actually OK. Remember, we only migrate the scheduling
> context, but the task as such won't ever execute on the remote CPU.

Yeah... makes sense. This patch is actually coming from the previous series,
maybe I was hitting a different issue with the sched_ext core. I'll remove this
one and repeat my tests.

Thanks,
-Andrea