On 02/17, Greg Kurz wrote: > > On 02/17/2011 09:29 PM, Oleg Nesterov wrote: >> On 02/17, Daniel Lezcano wrote: >>> >>> On 02/15/2011 08:01 PM, Oleg Nesterov wrote: >>>> >>>> I have to admit, I can't say I like this very much. OK, if we need >>>> this, can't we just put something into, say, signal->flags so that >>>> copy_process can check and create the new namespace. >>>> >>>> Also. I remember, I already saw something like this and google found >>>> my questions. I didn't actually read the new version, perhaps my >>>> concerns were already answered... >>>> >>>> But what if the task T does unshare(CLONE_NEWPID) and then, say, >>>> pthread_create() ? Unless I missed something, the new thread won't >>>> be able to see T ? >>> >>> Right. Is it really a problem ? I mean it is a weird use case where we >>> fall in a weird situation. >> >> But this is really weird! How it is possible that the parent can't see >> its own child? No matter which thread did fork(), the new process is > > Hmmm... I guess you mean the opposite. The way pid namespaces are > nested, parents always see their children. Well, yes. But it can't see this child using the same pid number, unless I missed something. > But indeed, the child thread > can't see its group leader and that's kind of unusual. This too. And to me this is more "kind of buggy". But yes, I am biased because I dislike this approach in general ;) And, once again, this patch also lacks the necessary s/nsproxy/atcive_pid_ns/ changes. Anyway. It is very possible I missed something. As I said, I didn't actually read this version and I forgot all I knew about this change before. But afaics this patch is buggy in its current form. Oleg. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
