linux-kernel - Re: [PATCH] sched: Relax a restriction in sched_rt_can

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] [day] [month] [year] [list]

Date:	Wed, 6 May 2015 11:12:45 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Tejun Heo <tj@...nel.org>
cc:	Peter Zijlstra <peterz@...radead.org>,
	Zefan Li <lizefan@...wei.com>,
	Mike Galbraith <umgwanakikbuti@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Cgroups <cgroups@...r.kernel.org>
Subject: Re: [PATCH] sched: Relax a restriction in sched_rt_can_attach()

On Tue, 5 May 2015, Tejun Heo wrote:
> On Tue, May 05, 2015 at 08:29:28PM +0200, Thomas Gleixner wrote:
> > As Peter said several times: hard failure is good and desired. It's a
> > very clear information on which people can act on. If the failures
> > modes are nilly-willy today, as you wrote somewhere, then we need to
> > fix that and make them consistent and understandable and not replace
> > them by half baken heuristics which postpone the failure to some point
> > where it is even less understandable.
> 
> There are no such magic heuristics because controllers need well
> defined behaviors when current is above limit anyway and behave
> exactly the same way no matter how that state is reached.  For

How would something go above limit in the first place if your resource
management is done proper?

  If a group has a resource limit, then it is not allowed to exceed
  that resource. So any attempt to use more resources must fail,
  period. There is no way to go above the limit.

  If you try to lower the limits of an existing group below the level
  which is already used, then this limit restriction attempt must
  fail.

That's the basic principle of resource management. And if you try to
avoid them, then you have a massive design failure. It's that simple.

Thanks,

	tglx




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