linux-kernel - Re: [PATCH] sched: staircase deadline misc fixes

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, 29 Mar 2007 08:54:55 +0200
From:	Mike Galbraith <efault@....de>
To:	Con Kolivas <kernel@...ivas.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	linux list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	ck list <ck@....kolivas.org>
Subject: Re: [PATCH] sched: staircase deadline misc fixes

Oh my, I'm on a roll here... somebody stop me ;-)

Some emphasis:

On Thu, 2007-03-29 at 08:29 +0200, Mike Galbraith wrote:
> On Thu, 2007-03-29 at 07:50 +0200, Mike Galbraith wrote:
> 
> > Opinion polls are nice, but I'm more interested in gathering numbers
> > which either validate or invalidate the claims of the design documents.
> 
> Suggestion: try the testcase that Satoru Takeuch posted.  The numbers I
> got with latest SD were no better than the numbers I got with the patch
> I posted to try to solve it.  Seems to me the numbers with SD should
> have been much better, but they in fact were not.
> 
> Running that thing, mainline's GUI was not usable, even with my patch,
> but neither was it usable with SD.  What's the difference between
> horrible with mainline and merely terrible with SD?  In both, the GUI
> ends up doing round-robin with a slew of hogs.  In mainline, this
> happens because the history logic can and does get it wrong sometimes,
> which this exploit deliberately triggers.  With SD, it's by design.

The much maligned history mechanism in mainline didn't start it's life
as an interactivity estimator, that's a name it acquired later.  What it
was first put there for was to ensure fairness for sleeping tasks.

I found it most ironic that the numbers I posted showed that mechanism
working perfectly, with an exploit that was designed specifically to
expose it's weakness, despite the deliberate tweaks that have gone in
tweaking it very heavily in the unfair direction, and this went
uncommented.  If I had run more of them, it would have shown that
weakness very well.  We all know that weakness exists.

What the numbers clearly showed was that sleeping tasks did not get the
fairness RSDL advertised with the particular test I ran, yet it went
uncommented/uncontested.  Anyone could have tested with the trivial
proggy of their choice... but nobody did.

The history mechanism is not only about interactivity, and never was. 

	-Mike

I'm gonna go piddle around with code now, much more fun than yacking :)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/