Re: setns vs unshare bug

[Serge Hallyn <serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>]

Quoting Pavel Emelyanov (xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org):
> 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.

Ooh!  Sorry, now I see.

-serge