Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > Ok. I see what you are trying to accomplish with this and honestly I > think it is silly. > > We should start the threads we need in the kernel, and if we need to > run clone_pid fine. I am not comfortable exporting clone_with_pid to > user space. Even if we create the task tree in userspace, I don't see why we can't have the parent of each nested pid_ns pass CLONE_NEWPID to clone_with_pid() instead of doing clone first and then unsharing the pidns? As for clone_with_pid(), I don't particularly like the semantics, but as was discussed over IRC, we could have clone_with_pid() return -EINVAL unless it is called while it is called from a task inside a restarting container. (and -EPERM if setting a pid in a pid_ns which was not created as part of the container) Eric do you dislike that any less? > As for the implementation of allocating a struct pid with a certain > set of pid values. I expect we can do that easily enough by > refactoring the pid allocator to be passed in the min/max pid to > allocate from, and have a special case that passes in a different set > of min/max values so we can allocate just the pid we need. What is wrong with Alexey's patch, which simply passes in the values themselves? Do you have another use in mind for the min/max pid values? > If the primary use for a userspace interface is restart I feel we are > doing it wrong. I think that's a good guideline, bad rule. Certainly possible that you're right that this is just pointing to in-kernel recreation of process tree as the way to go. I was getting that feeling myself, but then there are still very good reasons not to do that, as there are things which each task should do before completing sys_restart() which are best done in userspace. These include for instance creating virtual nics, and calling Oren's suggested 'cr_advise()' system calls. -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
