On 08/10/2012 07:08 PM, Pavel Emelyanov wrote: > On 08/10/2012 07:00 PM, Serge Hallyn wrote: >> Hi Pavel, >> >> I don't believe this is a bug. The fd is to a specific network >> namespace. If the target task later changes his namespace, that >> doesn't change the fact that you asked for access to the old >> namespace. >> >> You're worried about a race? > > No, it's not a race. The proc ns file doesn't reflect the actual state > of a task it belongs to, but instead has some internal state which is > not observable/controllable from the outside. Look at my proggie -- the > "else" branch does expects that setns will bring it into a new net, but > it only does so if proc dcache is empty! I mean -- I open a task's proc ns file _strictly_ _after_ that task called unshare, but happen to obtain an _old_ net namespace, because this old netns was cached on the task's proc file. Hope this explains better what I'm concerned about. Thanks, Pavel _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
