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

[Serge E. Hallyn]

Quoting Daniel Lezcano (daniel.lezcano at free.fr):
> 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 ?

Why?

> 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

I don't understand why it gets decremented twice before not being
checkpointable - or do you mean that by the time the nsproxy is
useful it will be 1?   2 is basically an init-only unused phase?

> Second clone | unshare (forbidden) => may_checkpoint becomes 0

Ok but if I

	unshare(CLONE_NEWNS)

I'll get a new nsproxy with an old uts_ns.  So we'll need
some (potentially complicated) logic at nsproxy creation to
decide whether the namespaces being cloned or not being cloned
impact the checkpointability of the new nsproxy...

Hmm.  I think I prefer making sure that the uts_ns is the
same for all checkpointed tasks :)

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