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: <4EB2F5CF.5010604@aljex.com>
Date:	Thu, 03 Nov 2011 16:13:03 -0400
From:	"Brian K. White" <brian@...ex.com>
To:	containers@...ts.linux-foundation.org
CC:	linux-kernel@...r.kernel.org, cgroups@...r.kernel.org
Subject: Re: [PATCH] new cgroup controller "fork"

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.

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?

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