linux-kernel - Re: [PATCH 2/2] sched/deadline: Temporary copy static parameters to boosted non-DEADLINE entities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191113093649.GI4131@hirez.programming.kicks-ass.net>
Date:   Wed, 13 Nov 2019 10:36:49 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Juri Lelli <juri.lelli@...hat.com>
Cc:     mingo@...hat.com, glenn@...ora.tech, linux-kernel@...r.kernel.org,
        rostedt@...dmis.org, vincent.guittot@...aro.org,
        dietmar.eggemann@....com, tglx@...utronix.de,
        luca.abeni@...tannapisa.it, c.scordino@...dence.eu.com,
        tommaso.cucinotta@...tannapisa.it, bristot@...hat.com
Subject: Re: [PATCH 2/2] sched/deadline: Temporary copy static parameters to
 boosted non-DEADLINE entities

On Wed, Nov 13, 2019 at 10:22:41AM +0100, Juri Lelli wrote:

> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index 26e4ffa01e7a..16164b0ba80b 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -4452,9 +4452,11 @@ void rt_mutex_setprio(struct task_struct *p, struct task_struct *pi_task)
> >  		if (!dl_prio(p->normal_prio) ||
> >  		    (pi_task && dl_entity_preempt(&pi_task->dl, &p->dl))) {
> >  			p->dl.dl_boosted = 1;
> > -			queue_flag |= ENQUEUE_REPLENISH;
> > -		} else
> > +			p->dl.deadline = pi_task->dl.deadline;
> > +		} else {
> >  			p->dl.dl_boosted = 0;
> > +			p->dl.deadline = p->dl.normal_deadline;
> > +		}
> >  		p->sched_class = &dl_sched_class;
> >  	} else if (rt_prio(prio)) {
> >  		if (dl_prio(oldprio))

> So, the problem is more related to pi_se->dl_runtime than its deadline.
> Even if we don't replenish at the instant in time when boosting happens,
> the boosted task might still deplete its runtime while being boosted and

I thought we ignored all runtime checks when we were boosted? Yes, that
is all sorts of broken, but IIRC we figured that barring something like
proxy-execution there really wasn't anything sane we could do wrt
bandwidth anyway.

Seeing how proper bandwidth handling would have the boosted task consume
the boostee's budget etc.. And blocking the entire boost chain when it
collectively runs out.