Re: [PATCH] sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting

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

On 24/02/26 14:45, Peter Zijlstra wrote:
> On Mon, Feb 09, 2026 at 10:46:18AM +0100, Juri Lelli wrote:
> 
> > > (afaict nothing clears dl_se::pi_se except rt_mutex_setprio() so that
> > > should still be valid here -- so we don't need to go find it again)
> > 
> > But, maybe with something like this? I believe we need to make things
> > right at this point "promoting" the now becoming lower prio class task
> > to DEADLINE (inheriting from the task it didn't inherit from in the
> > past). Maybe we can avoid checking pi_task since dl_prio(newprio). And
> > also move everything in an helper to remove ifdeffery.
> > 
> > ---
> > diff --git a/kernel/sched/syscalls.c b/kernel/sched/syscalls.c
> > index 6f10db3646e7f..856df1a22e3ca 100644
> > --- a/kernel/sched/syscalls.c
> > +++ b/kernel/sched/syscalls.c
> > @@ -655,6 +655,16 @@ int __sched_setscheduler(struct task_struct *p,
> >  			__setscheduler_params(p, attr);
> >  			p->sched_class = next_class;
> >  			p->prio = newprio;
> > +#ifdef CONFIG_RT_MUTEXES
> > +			if (dl_prio(newprio) && !dl_policy(policy)) {
> > +				struct task_struct *pi_task = rt_mutex_get_top_task(p);
> > +
> > +				if (pi_task) {
> > +					p->dl.pi_se = pi_task->dl.pi_se;
> > +					scope->flags |= ENQUEUE_REPLENISH;
> > +				}
> > +			}
> > +#endif
> >  		}
> >  		__setscheduler_uclamp(p, attr);
> 
> I'm still a bit confused on the pi_se thing; if this was a dl task, then
> rt_mutex_setprio() would've already set this to pi_task->dl.pi_se, no?

Let's say it's 'far from ideal', but we currently have

if (dl_prio(prio)) {
  if (!dl_prio(p->normal_prio) ||
    (pi_task && dl_prio(pi_task->prio) &&
     dl_entity_preempt(&pi_task->dl, &p->dl))) {  <--
        p->dl.pi_se = pi_task->dl.pi_se;
        scope->flags |= ENQUEUE_REPLENISH;
  } else {
    p->dl.pi_se = &p->dl;
  }

So, if the potential donor was DEADLINE, but with longer absolute
deadline, we don't boost. But, if the donor is still potential, we can
boost later when the holder becomes lower prio.

> 
> Anyway, yes something like that, possibly with a helper sounds fine.
> 

Will clean-up and resend.

Thanks,
Juri