Hi Max, I agree with what Tejun said, I just wanted to make a few specific points: > This patch introduces a new setting called "fork_remaining". When > positive, each successful fork decrements the value, and once it > reaches zero, no further forking is allowed, no matter how many of > those processes are still alive. The special value "unlimited" > disables the fork limit. I don't understand *why* you want this. cgroups are meant to deal with the accounting of *legitimate resources*, and I don't see how "the number of forks ever in a given cgroup" is a reasonable resource. Not to mention that it doesn't make sense IMO to make a limit that gets smaller over time when processes that have died and been freed > The goal of this limit is to have another safeguard against fork > bombs. It gives processes a chance to set up their child processes / > threads, but will be stopped once they attempt to waste resources by > continuously exiting and cloning new processes. This can be useful > for short-lived processes such as CGI programs. Processes don't "use up resources" after they've died and been freed (which is dealt with inside PIDs). Yes, lots of small processes that die quickly could (in principle) make hard work for the scheduler, but I don't see how "time spent scheduling in general" is a resource... Fork bombs aren't bad because they cause a lot of fork()s, they're bad because the *create a bunch of processes that use up memory*, which happens because they call fork() a bunch of times and **don't exit()**. -- Aleksa Sarai (cyphar) www.cyphar.com -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
