Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > Sukadev Bhattiprolu <sukadev@xxxxxxxxxxxxxxxxxx> writes: > The only real argument in favor of doing this in user space is greater > flexibility. Yyyyup. > I can see checkpointing/restoring a single thread process > without a pid namespace. Anything more and you are just asking for > trouble. > > A design that weakens security. How does it weaken security? It requires CAP_SYS_ADMIN, and, when targeted capabilities are added, it will require CAP_SYS_ADMIN to only those pid namespaces in which we choose a pid. > Increases maintenance costs. Does it really? It re-uses most of the existing code. More so than the only existing in-kernel restart code I've seen does. > All for > an unreliable result seems like a bad one to me. I've personally always been on the fence as to whether we rebuild the process tree in user-space or kernel. And I'm still on the fence, as nothing you've said has convinced me otherwise. > > | The pid assignment code is currently ugly. I asked that we just pass > > | in the min max pid pids that already exist into the core pid > > | assignment function and a constrained min/max that only admits a > > | single pid when we are allocating a struct pid for restart. That was > > | not done and now we have a weird abortion with unnecessary special cases. > > > > I did post a version of the patch attemptint to implement that. As > > pointed out in: > > > > http://lkml.org/lkml/2009/8/17/445 > > > > we would need more checks in alloc_pidmap() to cover cases like min or max > > being invalid or min being greater than max or max being greater than pid_max > > etc. Those checks also made the code ugly (imo). > > If you need more checks you are doing it wrong. The code already has min > and max values, and even a start value. I was just strongly suggesting > we generalize where we get the values from, and then we have not special > cases. (I'm not sure whether this argument is a separate one - regarding the implementation of choosing the pid - from the kernel-vs-userspace one or not, so will wait for a response to my other email about your API) thanks, -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers