linux-kernel - Re: [RFC -v2 PATCH 2/3] sched: add yield

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: <4D0DA15B.7080401@redhat.com>
Date:	Sun, 19 Dec 2010 08:08:27 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Mike Galbraith <mgalbraith@...e.de>
CC:	Rik van Riel <riel@...hat.com>, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Chris Wright <chrisw@...s-sol.org>
Subject: Re: [RFC -v2 PATCH 2/3] sched: add yield_to function

On 12/18/2010 09:13 PM, Mike Galbraith wrote:
> On Sat, 2010-12-18 at 19:08 +0200, Avi Kivity wrote:
> >  On 12/17/2010 09:15 AM, Mike Galbraith wrote:
> >  >  BTW, with this vruntime donation thingy, what prevents a task from
> >  >  forking off accomplices who do nothing but wait for a wakeup and
> >  >  yield_to(exploit)?
> >  >
> >
> >  What's the difference between that and forking off accomplices who
> >  run(exploit) directly?
>
> The clock still advances.  What I described is a clock stopper.

That's scheduler jargon, I'm not familiar with scheduler internals.  
Let's talk about this at a high level, since whenever I describe it in 
scheduler terms I'm likely to get it wrong.

If there are N tasks on the machine, each is entitled to 1/N of the 
machine's cpu resources (ignoring nice and cgroups for the moment).  
What I'd like is for one task to temporarily pass a portion of its 
entitlement to another.  No other task's entitlement is affected; they 
still get their 1/N.

If a task donates its entitlement and immediately commits suicide, still 
we won't have fundamentally changed anything; the task could have kept 
itself alive and consumed that entitlement, so the scheduler was already 
prepared to give it this entitlement so nothing was gained by the 
forking task.  The problem of fork() creating new entitlements out of 
thin air has nothing to do with directed yield, and is solved by cgroups.

We already do something similar with priority inheritance.  This doesn't 
involve cpu entitlement, but we have the same situation where a task's 
ability to make progress depends on another task receiving cpu time.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
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/