Re: [PATCH 04/12] sched_ext: Block proxy donors across scheduler transitions

On Wed, Jul 22, 2026 at 01:26:03PM -1000, Tejun Heo wrote:
> Hello, Andrea.
> 
> On Tue, Jul 21, 2026 at 08:31:25AM +0200, Andrea Righi wrote:
> > @@ -7168,7 +7168,8 @@ static void __sched notrace __schedule(int sched_mode)
> >  		 * task_is_blocked() will always be false).
> >  		 */
> >  		try_to_block_task(rq, prev, &prev_state,
> > -				  !task_is_blocked(prev));
> > +				  !task_is_blocked(prev) ||
> > +				  !scx_allow_proxy_exec(prev));
> 
> The condition fits on one line.

Ack.

> 
> > @@ -7721,6 +7722,8 @@ void rt_mutex_setprio(struct task_struct *p, struct task_struct *pi_task)
> >  	if (prev_class != next_class)
> >  		queue_flag |= DEQUEUE_CLASS;
> >
> > +	scx_prepare_setscheduler(p, next_class);
> > +
> >  	scoped_guard (sched_change, p, queue_flag) {
> 
> Calling directly into sched_ext from rt_mutex_setprio() and
> __sched_setscheduler() isn't the prettiest. This may want to be a class
> callback invoked from sched_change_begin() on the incoming class before the
> queued state is recorded - the existing ones are either too late or on the
> outgoing class.
> 
> Peter, what do you think?

Yeah, makes sense to me, it'd be a lot cleaner. If Peter is ok with that, I can
add a preparatory patch to introduce this new class callback, something like
prepare_switch()?

> 
> > +void scx_prepare_setscheduler(struct task_struct *p,
> > +			      const struct sched_class *next_class)
> 
> Fits on one line. Ditto for the declaration in ext.h.

Ack.

Thanks,
-Andrea