On Thu, May 07, 2015 at 01:29:59PM +0300, Cyrill Gorcunov wrote: > On Thu, May 07, 2015 at 01:17:27PM +0300, Vladimir Davydov wrote: > > > We're creating cgroups for container on ve0 but bindmount them > > > from inside of container, thus on userspace level (via config file) > > > we can setup which cgroups are allowed for use. Still we're not > > > limiting anyhow creating new sub-cgroups (via mkdir) inside > > > container, and this one should be performance penalty mainly > > > (new cgroup allocation is done via direct kzalloc without > > > any memory limits as far as I understart). > > > > Actually, it is accounted to memcg, just like any kmalloc, but the > > problem isn't that we miss accounting. The problem is that the more > > I see, it's deep inside of slab/slub code, thanks. > > > features we allow to use from inside a container, the more different > > types of kernel objects a container can create, the more potential > > security issues we have. E.g. on reclaim the kernel walks over all > > memory cgroups, as a result a container user can try to DOS the node by > > creating thousands of cgroups. > > So maybe we should limit the number of nested cgroups in container? > There is root->number_of_cgroups maybe we should setup some limit > on ve config.
The more parameters we have the worse. What should be a default value for this? 10, 50, 100? And why? Can we guarantee that the user of a container won't be able to exploit the system with this particular number of cgroups? Can we be sure that this particular number of cgroups will be enough? I don't think so. If something goes wrong, one can disable cgroups in a container altogether, otherwise he has to take the risk. _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel