2012/4/18 KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx>: > (2012/04/18 1:52), Glauber Costa wrote: > >> >>>> In short, I don't think it's better to have task-counting and fd-counting in memcg. >>>> It's kmem, but it's more than that, I think. >>>> Please provide subsys like ulimit. >>> >>> So, you think that while kmem would be enough to prevent fork-bombs, >>> it would still make sense to limit in more traditional ways >>> (ie. ulimit style object limits). Hmmm.... >>> >> >> I personally think this is namespaces business, not cgroups. >> If you have a process namespace, an interface that works to limit the >> number of processes should keep working given the constraints you are >> given. >> >> What doesn't make sense, is to create a *new* interface to limit >> something that doesn't really need to be limited, just because you >> limited a similar resource before. >> > > > Ok, limitiing forkbomb is unnecessary. ulimit+namespace should work. > What we need is user-id namespace, isn't it ? If we have that, ulimit > works enough fine, no overheads. I have considered using NR_PROC rlimit on top of user namespaces to fight forkbombs inside a container. ie: one user namespace per container with its own rlimit. But it doesn't work because we can have multiuser apps running in a single container. -- 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
