Re: [PROCFS] [NETNS] issue with /proc/net entries

[Benjamin Thery]

Eric W. Biederman wrote:
> Benjamin Thery <benjamin.thery@xxxxxxxx> writes:
>
> > Hi Eric,
> >
> > While testing the current network namespace stuff merged in net-2.6.25,
> > I bumped into the following problem with the /proc/net/ entries.
> > It doesn't always display the actual data of the current namespace,
> > but sometime displays data from other namespaces.
> >
> > I bisected the problem to the commit:
> > "proc: remove/Fix proc generic d_revalidate"
> > 3790ee4bd86396558eedd86faac1052cb782e4e1
> >
> > The problem: If a process in a particular network namespace changes
> > current directory to /proc/net, then processes in other network
> > namespaces trying to look at /proc/net entries will see data from the
> > first namespace (the one with CWD /proc/net). (See test case below).
> >
> > As you comments in the commit suggest, you seem to be aware of some
> > issues when CONFIG_NET_NS=y. Is it one of these corner cases you
> > identified? Any idea on how we can fix it?
>
> Yes.  It isn't especially hard.   I have most of it in my queue
> I just need to get the silly patches out of there.
>
> Essentially we need to fix the caching of proc_generic entries,
> So that we can have a proper d_revalidate implementation.
>
> To get d_revalidate and the caching correct for /proc/net will take
> just a bit more work.  We need to make /proc/net a symlink
> to something like /proc/self/net so that we don't get excess
> revalidates when switching between different processes.
>
> Or else we can't properly implement the case you have described.
> Where being in the directory causes the wrong version of /proc/net
> to show up. Changing the contents of the dentry for /proc/net
> should only happen during unshare.  Not when we switch between
> processes or else we get into the d_revalidate leaks mount points
> problem again.
>
> We also need the check to see if something is mounted on top of
> us before we call drop the dentry.  But if we don't even try until
> we know the dentry is invalid it should not be too bad.

Thanks for all the details.
I'll put this issue on my "netns current limitations" list until
it's solved.

Benjamin


> Eric


--
B e n j a m i n   T h e r y  - BULL/DT/Open Software R&D

   http://www.bull.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/