Glauber Costa <glommer@xxxxxxxxxxxxx> writes: > On 01/18/2013 12:18 PM, Eric W. Biederman wrote: >> Glauber Costa <glommer@xxxxxxxxxxxxx> writes: >> >>> On 01/18/2013 11:48 AM, Serge Hallyn wrote: >>>> Quoting Glauber Costa (glommer@xxxxxxxxxxxxx): >>>>> On 01/17/2013 11:01 PM, Eric W. Biederman wrote: >>>>>> What are the practical problems with control groups that makes them >>>>>> undesirable/hard to use with namespaces? >>>>>> >>>>>> What would it take to fix the problems with control groups? >>>>> There aren't, from my PoV. >>>>> When I run containers, for instance, I basically join all namespaces, >>>>> configure all groups, and everything I can. >>>>> >>>>> I do know, however, that not every use case is like that, and those >>>>> things tends to be very loosely coupled. >>>>> >>>>> So what I am worried about, is not a valid container usage where you >>>>> have your constraints configured. But if I login into a box as a normal >>>>> user, and that now allows me to create a userns, and maliciously fire a >>>>> big tmpfs from there, cgroups will not gonna be there for me - it's not >>>>> a container box, is just something I am trying to break. >>>> >>>> Hm. So basically we would, ideally, find a way to make it so that if >>>> uid 500 creates a new userns and, therein, mounts a tmpfs, then that >>>> tmpfs gets accounted and limited along with uid 500's RSS? >>>> >>> >>> Dunno. >>> >>> One option would be to start establishing stronger connections between >>> cgroups and namespaces in a sane way. And then, we only allow such >>> mounts when you are actually cgroup backed. >>> >>> Again, I am not concerned with sane setups in here, but much more with >>> normal users in normal systems taking advantage of this. >> >> For me this translates into it would be good if we can get distros to >> establish some good default limits for when they enable user namespaces. >> >> At a practical level I just looked and my current distribution does not >> limit the size of processes I can create or the amount of memory those >> processes can use. So unless the distro I am looking at is strongly >> atypical any kind of memory limit is certainly worth providing but won't >> help much. >> >> Are memory control groups at this point palatable to general purpose >> distributions? If memory control groups are not that does seem to be an >> argument that we need something better. Last I looked memory control >> groups had some ugly overheads and doubled the size of struct page so >> there are certainly reasons why memory control groups might be a problem. >> > We are actively placing a lot of effort into reducing this overhead. > >> Serge does ubunutu enable memory control groups? >> > I believe at least systemd uses it. So I just finished my basic review of the current state of memory control groups. Memory control groups do succesfully control memory all kinds of memory (if properly configured) and the overhead has been reduced to 2/7 the size of struct page on 64bit systems. <tangent> By my rough calculations the memory control group overhead is 4MiB per gigabyte. It looks like that overhead can be pretty easily cut in half by simply embedding the flags into the low bits of the memory_control group pointer. And I still don't understand why page_cgroup is not a member of struct page. But whatever memory control groups have much less per page overhead than they used to. </tangent> So it looks like distros and everyone else who enable user namespaces and allow multiple users to be logged in at the same to to setup memory control groups to limit the trouble their users can get into. I think I will have to add a patch to document that recomendation. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
