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]

Date:	Fri, 4 Nov 2011 11:11:26 -0200
From:	Glauber Costa <glommer@...allels.com>
To:	Li Zefan <lizf@...fujitsu.com>
CC:	"Brian K. White" <brian@...ex.com>, <cgroups@...r.kernel.org>,
	<containers@...ts.linux-foundation.org>,
	<linux-kernel@...r.kernel.org>, <max@...mpel.org>
Subject: Re: [PATCH] new cgroup controller "fork"

On 11/04/2011 01:03 AM, Li Zefan wrote:
> 于 2011年11月04日 05:54, Glauber Costa 写道:
>> 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.
>
> Quoted from Lennart's reply in another mail thread:
>
> "Given that shutting down some services might involve forking off a few
> things (think: a shell script handling shutdown which forks off a couple
> of shell utilities) we'd want something that is between "from now on no
> forking at all" and "unlimited forking". This could be done in many
> different ways: we'd be happy if we could do time-based rate limiting,
> but we'd also be fine with defining a certain budget of additional forks
> a cgroup can do (i.e. "from now on you can do 50 more forks, then you'll
> get EPERM)."
>
> (http://lkml.org/lkml/2011/10/19/468)
>
> The last sentence suggests he might like this fork controller.

Well, If I understand Frederic's work well enough, this can be achieved 
by setting the task limit to 0 in his controller. No?

Because being lower than your limit won't kick tasks out, the practical 
effect is that no forks will be allowed in the group with this setting.

So for time-based rate limiting, it is trivial to just set it to 0 after 
x seconds.

For other uses, we can watch the task counter increase until a certain 
value, and then set the limit to 0.

Max, wouldn't it be enough for your use?
--
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/