Re: [PATCH 09/18] sched_ext: Block proxy donors across scheduler transitions

[Peter Zijlstra]

On Thu, Sep 10, 2026 at 12:53:35PM +0200, Peter Zijlstra wrote:
> On Mon, Aug 31, 2026 at 03:42:19PM +0200, Andrea Righi wrote:

> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index f142ab455b797..4bd956182af8d 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -11302,6 +11302,15 @@ sched_change_begin(struct task_struct *p, const struct sched_class *next_class,
> >  		flags |= DEQUEUE_NOCLOCK;
> >  	}
> >  
> > +	/*
> > +	 * Don't carry retained proxy state across scheduling class changes.
> > +	 * Compatible RT/DL PI transitions could preserve the session so that a
> > +	 * boosted donor continues proxy-executing its lock owner. Defining which
> > +	 * class transitions can safely retain that state is left for future work.
> > +	 */
> > +	if ((flags & DEQUEUE_CLASS) && next_class != p->sched_class)
> 
> That's a tautology, having DEQUEUE_CLASS means next_class !=
> ->sched_class.
> 
> > +		sched_proxy_block_task(rq, p);
> > +
> >  	if ((flags & DEQUEUE_CLASS) && p->sched_class->switching_from)
> >  		p->sched_class->switching_from(rq, p);
> >  

> Hmmmm... I don't like this. I was expecting this
> sched_proxy_block_task() thing to be called in the big switcheroo
> function when loading one of these ext thing. (scx_root_enable_ or
> somesuch).
> 
> We most certainly don't want to do this on every sched class change. It
> isn't even gated by scx_allow_proxy_exec().

Why not do:

switching_to_scx():

+	if (!scx_allow_proxy_exec(p))
+		sched_proxy_block_task(rq, p);