Hello, On Mon, Jul 21, 2014 at 01:46:55PM +0200, Michal Hocko wrote: > Even then, I do not see how would this fork-bomb prevention work without > causing OOMs and killing other processes within the group. The danger > would be still contained in the group and prevent from the system wide > disruption. Do we really want only such a narrow usecase? Does that really matter? I don't buy the usefulness of the various suggested partial failure modes. For example, is fork-bomb actually something isolatable by not granting more forks? Doing so is likely to cripple the cgroup anyway, which apparently needed forking to operate. Such partial failure mode would only be useful iff the culprit is mostly isolated even in the cgroup, stops forking once it starts to fail, the already forked excess processes can be identified and killed somehow without requiring forking in the cgroup, and fork failures in other parts of the cgroup hopefully hasn't broken the service provided by the cgroup yet. In the long term, we should have per-cgroup OOM killing and terminate the cgroups which fail to behave. I think the value is in the ability to contain such failures, not in the partial failure modes that may or may not be salvageable without any way to systematically determine which way the situation is. Short of being able to detect which specific process are fork bombing and take them out, which I don't think can or should, I believe that fork bomb protection should be dealt as an integral part of generic memcg operation. Thanks. -- tejun -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>