[Devel] Re: [PATCH] [RFC] c/r: Add UTS support

[Daniel Lezcano]

Serge E. Hallyn wrote:
> Quoting Daniel Lezcano (daniel.lezcano at free.fr):
>   
>> Dan Smith wrote:
>>     
>>> DL> I guess it will be esay to implement with a nsproxy level counter.
>>> DL> Each time you unshare, the new nsproxy count is incremented.
>>> DL> Assuming the init_nsproxy is level 0, when the nsproxy counter is
>>> DL> > 1, the process is uncheckpointable.
>>>
>>> This should also be possible by just making sure that the nsproxy of
>>> the root process being checkpointed is the same as any of the
>>> children, correct?  That way we avoid having to modify the core
>>> nsproxy bits and can still reject any nested namespaces.
>>>   
>>>       
>> Right, this is another option. The nsproxy counter will allow to flag at 
>> runtime a process to be uncheckpointable. The nsproxy comparison will 
>> detect nested nsproxies at checkpoint time.
>>     
>
> Or, to stick more to the resource->may_checkpoint way of doing it, you
> setbit(&nsproxy->uts_ns->may_checkpoint, 0) when the uts_ns is
> created, and anytime a task does clone(CLONE_NEWUTS) or
> unshare(CLONE_NEWUTS), you clear the bit on the parent uts_ns.
>   
Hmm, you will need to add a back pointer for the nsproxy | utsns parent, 
no ?
What I was proposing is a counter directly in the nsproxy. Maybe instead 
of initializing it to zero, it can be initialized to the max supported 
nested level ( only one right now) and decrement each time a clone or a 
unshare is done whatever the namespace.

init nsproxy->may_checkpoint = 2
First clone | unshare => for the new nsproxy the counter may_checkpoint 
becomes 1
Second clone | unshare (forbidden) => may_checkpoint becomes 0

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