| Again, strange but harmless. Right nothing broken, just trying to disable the strangeness till usage becomes clear. | | > To keep pid namespace semantics simple, prevent container-inits from using | > CLONE_PARENT at least until we have a better understanding of CLONE_PARENT | > and pid-namespace interactions. | | Yes, perhaps makes sense. | | > --- linux-mmotm.orig/kernel/fork.c 2009-06-17 18:23:23.000000000 -0700 | > +++ linux-mmotm/kernel/fork.c 2009-06-17 19:17:54.000000000 -0700 | > @@ -974,6 +974,14 @@ static struct task_struct *copy_process( | > if ((clone_flags & CLONE_SIGHAND) && !(clone_flags & CLONE_VM)) | > return ERR_PTR(-EINVAL); | > | > + /* | > + * To keep pid namespace semantics simple, prevent container-inits | > + * from creating siblings. | > + */ | > + if ((clone_flags & CLONE_PARENT) && | > + is_container_init(current) && !is_global_init(current)) | | Both is_ checks are not right afaics. There are per-thread. This means | that container-init can do clone(CLONE_THREAD), and then this thread | does CLONE_PARENT and fools copy_process(). Good point. Should check the tgid. | | As for !is_global_init(). I never understood what should we do if the | global init does CLONE_PARENT, this attaches another process to swapper, | not good. Agree, like I replied to Eric, I just was not sure there were any existing users of CLONE_PARENT :-( I could make a separate patch in this set to just disable CLONE_PARENT for global init. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
