linux-kernel - Re: [RFC][PATCH 05/22] sched: SCHED

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]

Date:	Thu, 11 Nov 2010 02:02:05 +0100
From:	Raistlin <raistlin@...ux.it>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Chris Friesen <cfriesen@...tel.com>, oleg@...hat.com,
	Frederic Weisbecker <fweisbec@...il.com>,
	Darren Hart <darren@...art.com>,
	Johan Eker <johan.eker@...csson.com>,
	"p.faure" <p.faure@...tech.ch>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Claudio Scordino <claudio@...dence.eu.com>,
	michael trimarchi <trimarchi@...is.sssup.it>,
	Fabio Checconi <fabio@...dalf.sssup.it>,
	Tommaso Cucinotta <cucinotta@...up.it>,
	Juri Lelli <juri.lelli@...il.com>,
	Nicola Manica <nicola.manica@...i.unitn.it>,
	Luca Abeni <luca.abeni@...tn.it>,
	Dhaval Giani <dhaval@...is.sssup.it>,
	Harald Gustafsson <hgu1972@...il.com>,
	paulmck <paulmck@...ux.vnet.ibm.com>
Subject: Re: [RFC][PATCH 05/22] sched: SCHED_DEADLINE policy implementation

On Wed, 2010-11-10 at 20:43 +0100, Peter Zijlstra wrote:
> On Fri, 2010-10-29 at 08:30 +0200, Raistlin wrote:
> > + * We are being explicitly informed that a new instance is starting,
> > + * and this means that:
> > + *  - the absolute deadline of the entity has to be placed at
> > + *    current time + relative deadline;
> > + *  - the runtime of the entity has to be set to the maximum value.
> 
> When exactly are we a new instance? From a quick look dl_new gets set
> after a sched_setscheduler() call, is that the only way?
> 
One of the only two ways. Later in the queue, that flag is set by a new
system call, i.e., sched_wait_interval, that can be used to inform the
scheduler (for example at the end of a periodic/sporadic job) that an
instance just ended. Moreover, it can be exploited by a task which want
the scheduler to wake it up when it can be given its full runtime.
It as been added as a consequence of the discussion happened in Dresden,
at last year RTLWS, aside of my presentation...

Whether or not this could be useful, I don't know, and I accept comments
as usual. My opinion is that it might be something worthwhile to have,
especially from the point of view of hard real-time-ish scenarios, but
we can remove it appears unnecessary.

> Could a task calling sched_setscheduler() on itself cheat the system?
>
I obviously might be wrong (especially at this time), but I would say no
for the following reasons.

If you are an overrunning -deadline task calling sched_setscheduler()
the deactivate_task->dequeue_task->dequeue_task_dl() below will trigger
the bandwidth enforcement, i.e., will set dl_throttled=1 and start
dl_timer:
	...
        on_rq = p->se.on_rq;                                                                                          
        running = task_current(rq, p);                                                                                
        if (on_rq)
                deactivate_task(rq, p, 0);
        if (running)
                p->sched_class->put_prev_task(rq, p);
	...

Later, this enqueue:
	...
	if (running)                                                                                                  
                p->sched_class->set_curr_task(rq);                                                                    
        if (on_rq) {
                activate_task(rq, p, 0);                                                                              
                                                                                                                      
                check_class_changed(rq, p, prev_class, oldprio, running);
        }
	...

even if it will find dl_new=1, will not enqueue the task back in its
dl_rq (since dl_throttled=1). The actual enqueueing happens at the
firing of dl_timer, where an update instead than a replenishment will be
performed, right because of the fact that dl_new=1. This means the
runtime will be fully replenished and the deadline moved toward
rq->clock+dl_se->dl_deadline.

Did this answer your question?

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

http://blog.linux.it/raistlin / raistlin@...ga.net /
dario.faggioli@...ber.org

Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)