OL> So what happens in the following scenario: OL> * task A is the container init(1) OL> * A calls fork() to create task B OL> * B calls unshare(CLONE_NEWUTS) OL> * B calls clone(CLONE_PARENT) to create task C In the previous version of the patch, I failed the checkpoint if this was the case by making sure that all tasks in the set had the same nsproxy. You said in IRC that this was already done elsewhere in the infrastructure, but now that I look I don't see that anywhere. The check I had was in response to Daniel's comments about avoiding the situation for the time being by making sure that all the tasks had the same set of namespaces (i.e. the same nsproxy at the time of checkpoint). OL> Two approaches to solve this are: OL> a) Identify, in mktree, that this was the case, and impose an OL> order on the forks/clones to recreate the same dependency (an OL> algorithm for this is described in [1]) OL> b) Do it in the kernel: for each nsproxy (identified by an objref) OL> the first task that has it will create it during restart, in or OL> out of the kernel, and the next task will simply attach to the OL> existing one that will be deposited in the objhash. I think that prior discussion led to the conclusion that simplicity wins for the moment, but if you want to solve it now I can cook up some changes. -- Dan Smith IBM Linux Technology Center email: danms@xxxxxxxxxx _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers