Re: [PATCH] new cgroup controller "fork"

[Glauber Costa <glommer@parallels.com>]

On 11/03/2011 04:51 PM, Max Kellermann wrote:
> On 2011/11/03 19:21, Alan Cox<alan@lxorguk.ukuu.org.uk>  wrote:
>>> After little discussion, nobody seemed to be interested in it, and
>>> nobody merged it.  I reposted it today, not knowing somebody else had
>>> come up with a similar idea meanwhile.
>>
>> I don't really see a meaningful use case for this. Why should millions of
>> users have this stuff in their kernel. What's the general purpose use
>> case we should all be excited about ?
>
> Putting a reasonable limit on jobs that are expected to run only for a
> limited amount of time, with a limited amount of total resources.  For
> example: CGI, cron jobs, backup, munin plugins, virus scanners and
> other email filters, procmail, ... - when the job is done, the group
> can be deleted, and new instances will run in a new group.
>
> With just RLIMIT_NPROC or task_counter, you can limit the total number
> of processes, but it will not stop a fork bomb - it will only slow it
> down.  The fork bomb will still bounce between 1 and the limit, and
> consume lots of resources for forking and exiting.
>
> (Glauber: the above should answer your last email, too)

Yet, the damage a fork bomb can pose into the system this way is 
severely limited. Combined with the cpu controller to guarantee that 
this group of process will never take the whole cpu for themselves,
you have almost everything you need, if not everything.

> Similar existing feature: RLIMIT_CPU.  Millions of users have it in
> their kernels, but nobody uses it nowadays.  And it's not even
> optional.
>
> Btw. I have no problem with maintaining this patch (and a whole bunch
> of others) in my proprietary git repository at work forever.  They're
> very useful for my employer.  I'm just trying to be a good citizen by
> sharing them.

Well, one alternative is to try to rebase your work on top of -mm, 
taking Frederic's work into account. What we really don't need, is 
another cgroup for that. So if you manage to convince people that this 
is really a win - haven't convinced me so far - the way to go is 
enhancing the existing fork cgroup.

> Max