[Devel] Re: cgroup attach/fork hooks consistency with the ns_cgroup

[Daniel Lezcano]

Serge E. Hallyn wrote:
> Quoting Paul Menage (menage at google.com):
>   
>> On Wed, Jun 17, 2009 at 2:26 PM, Serge E. Hallyn<serue at us.ibm.com> wrote:
>>     
>>> The ns cgroup is really only good for preventing root in a container
>>> from escaping its cgroup-imposed limits.  The same can be done today
>>> using smack or selinux, and eventually will be possible using user
>>> namespaces.  Would anyone object to removing ns_cgroup?
>>>       
>> Sounds reasonable to me. It feels to me that there ought to be some
>> good way to integrate namespaces and cgroups, but I'm not quite sure
>> exactly how, and ns_cgroup sort of hovers in the "toy" category rather
>> than something very useful.
>>     
>
> So the question becomes: does the presence of the ns cgroup constitute
> an API?  Can we just yank it out?
>
> Daniel, AFAIK liblxc is the only thing that actually uses it.  Do
> you mind manually moving the container init into a new cgroup?
>   

It is not a big deal to manually create and attach to the cgroup and I 
would prefer to remove the ns_cgroup if that helps to keep the cgroup 
behaviour consistent.
But the behaviour will change, no ? I mean the ns_cgroup clones the 
cgroup parent so we inherit its values. If we remove the ns_cgroup, that 
won't happen and I will have to handle some specific cases. For example, 
cpuset.cpus and cpuset.mems won't be filled and I will not be able to 
attach until I set them, so I have to be aware of this control group in 
the code and copy the values from the parent. That's annoying, I tried 
to have the liblxc cgroup code generic so it supports any kind of cgroup :/

There isn't a rule saying that we will inherit the values set by the 
parent ? If it is case, maybe we can remove the ns_cgroup and fix the 
cpuset at the same time, no ?

By the way, Andrew complained when we changed the name of the ns_cgroup 
"node_<pid>" by "<pid>" that we don't have to change the api when 
something is in the kernel. IMO, he won't be happy if we remove the 
ns_cgroup :/
Maybe, we can first fix the ns_cgroup hook problem by moving the 
ns_cgroup_clone after cgroup_fork_callbacks and propose a cgroup related 
to the namespaces. When we activate this new cgroup that disables the 
ns_cgroup and we put this cgroup_namespace as default in the Kconfig, no ?

Thanks
-- Daniel


_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers