Serge E. Hallyn wrote: > Quoting Daniel Lezcano (daniel.lezcano@xxxxxxx): > >> 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@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
