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: <1299588399.2308.1424.camel@twins>
Date:	Tue, 08 Mar 2011 13:46:39 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Mike Galbraith <efault@....de>
Cc:	Yong Zhang <yong.zhang0@...il.com>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [patchlet] sched: fix rt throttle runtime borrowing

On Mon, 2011-03-07 at 15:27 +0100, Mike Galbraith wrote:
> sched: fix rt throttle runtime borrowing
> 
> If allowed to borrow up to rt_period, the throttle has no effect on an out
> of control RT task, allowing it to consume 100% CPU indefinitely, blocking
> system critical SCHED_NORMAL threads indefinitely.
> 
> To make the throttle a more effective safety mechanism, disable borrowing
> by default. while providing an opt-in switch for those who know the risks.
> Also fix the throttle such that it never silently bumps rt_runtime to the
> point that it disables itself (rt_runtime >= rt_period).
> 
> Convert balance_runtime() and do_balance_runtime() to void since their
> return values are never used.
> 
> Signed-off-by: Mike Galbraith <efault@....de>

I'm very hesitant here, pretty much all of the sched_rt cgroup stuff
needs to be thrown out and rewritten. Adding more knobs to it isn't
going to make things much better.

(I'd myself much prefer to simply not support SCHED_FIFO/RR at all, but
seeing as POSIX mandates that crap there's really no choice there).

Also, how much of a problem is it really? When I start a FIFO spinner on
my machine I can still ssh in and kill the thing.

Not allowing 100% FIFO usage on SMP is going to make it very very hard
to implement any kind of fifo-cgroup stuff.


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ