linux-kernel - Re: [PATCH] new cgroup controller "fork"

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: <4EB30DAF.4090704@parallels.com>
Date:	Thu, 3 Nov 2011 19:54:55 -0200
From:	Glauber Costa <glommer@...allels.com>
To:	"Brian K. White" <brian@...ex.com>
CC:	<containers@...ts.linux-foundation.org>, <cgroups@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] new cgroup controller "fork"

On 11/03/2011 06:13 PM, Brian K. White wrote:
> On 11/3/2011 3:25 PM, Glauber Costa wrote:
>> On 11/03/2011 05:20 PM, Max Kellermann wrote:
>>> On 2011/11/03 20:03, Alan Cox<alan@...rguk.ukuu.org.uk> wrote:
>>>> Sure - I'm just not seeing that a whole separate cgroup for it is
>>>> appropriate or a good plan. Anyone doing real resource management needs
>>>> the rest of the stuff anyway.
>>>
>>> Right. When I saw Frederic's controller today, my first thought was
>>> that one could move the fork limit code over into that controller. If
>>> we reach a consensus that this would be a good idea, and would have
>>> chances to get merged, I could probably take some time to refactor my
>>> code.
>>>
>>> Max
>> I'd advise you to take a step back and think if this is really needed.
>> As Alan pointed out, the really expensive resource here is already being
>> constrained by Frederic's controller.
>
> I think this really is a different knob that is nice to have as long as
> it doesn't cost much. It's a way to set a max lifespan in a way that
> isn't really addressed by the other controls. (I could absolutely be
> missing something.)
>
> I think Max explained the issue clearly enough.

He did, indeed.

> It doesn't matter that the fork itself is supposedly so cheap.
>
> It's still nice to have a way to say, you may not fork/die/fork/die/fork
> in a race.
>
> What's so unimaginable about having a process that you know needs a lot
> of cpu and ram or other resources to do it's job, and you expressly want
> to allow it to take as much of those resources as it can, but you know
> it has no need to fork, so if it forks, _that_ is the only indication of
> a problem, so you may only want to block it based on that.
>
> Sure many other processes would legitimately fork/die/fork/die a lot
> while never exceeding a few total concurrent tasks, and for them you
> would not want to set any such fork limit. So what?
>
As I said previously, he knows his use cases better than anyone else.
If a use case can be found in which the summation of cpu+task 
controllers is not enough, and if this is implemented as an option to 
the task controller, and does not make it:
1) confusing,
2) more expensive,

then I don't see why not we shouldn't take it.
--
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/