linux-kernel - Re: RFC for a new Scheduling policy/class in the Linux-kernel

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: <1247600837.4839.128.camel@Palantir>
Date:	Tue, 14 Jul 2009 21:47:17 +0200
From:	Raistlin <raistlin@...ux.it>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Douglas Niehaus <niehaus@...c.ku.edu>,
	Henrik Austad <henrik@...tad.us>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Bill Huey <billh@...ppy.monkey.org>,
	Linux RT <linux-rt-users@...r.kernel.org>,
	Fabio Checconi <fabio@...dalf.sssup.it>,
	"James H. Anderson" <anderson@...unc.edu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ted Baker <baker@...fsu.edu>,
	Dhaval Giani <dhaval.giani@...il.com>,
	Noah Watkins <jayhawk@....ucsc.edu>,
	KUSP Google Group <kusp@...glegroups.com>,
	Tommaso Cucinotta <cucinotta@...up.it>,
	Giuseppe Lipari <lipari@...is.sssup.it>
Subject: Re: RFC for a new Scheduling policy/class in the Linux-kernel

On Mon, 2009-07-13 at 19:28 +0200, Peter Zijlstra wrote:
> > - analyzable from the real-time theorist's point of view... Which is
> >   (un?)fortunately what we are :-)
> > - possible to implement... Which is not always (un!)fortunately obvious 
> >   here :-)
> 
> I would very much like a proper theoretical foundation for whatever we
> end up with ;-)
> 
Well, thus let's hope to manage in it! :-D

> > Very basically: from the analysis point of view one easy and effective
> > solution would be to have the blocked-running tasks --i.e., the tasks
> > blocked on some lock that have been left on the rq to proxy-execute the
> > lock owner-- busy waiting while the lock owner is running. This allows
> > for retaining a lot of nice properties BWI already has, as far as
> > analyzability is concerned.
> 
> Right, practically we cannot do this, since we expose the block graph to
> userspace and you could in userspace construct a program that would
> exploit this spinning to DoS the system.
> 
I know and I share this belief with you, as I wrote in my original
mail... Even if I must say that it would not be a _real_ spinning, such
as raw_spinlock_t, with irq and preemption disabled (like in FMLP), but
only a mean to --preemptively-- consume some budget to avoid
schedulability to be lost!
Thus, I'm not sure it could be the basis for a DoS, especially if tasks
are, individually, as a group or as a whole class, enclosed within
groups (we used to call them reservations as well).

Anyway I'm aware that CPU bandwidth would be wasted, and that this is an
issue in systems like Linux... That's why we are striving for something
better... :-P

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" (198 bytes)