On Wed, Apr 11, 2012 at 09:37:33PM +0400, Stanislav Kinsbursky wrote: > 11.04.2012 21:19, J. Bruce Fields пишет: > >On Wed, Apr 11, 2012 at 05:08:46PM +0400, Stanislav Kinsbursky wrote: > >>11.04.2012 15:48, Jeff Layton пишет: > >>>>>>>One thing that puzzles me at the moment. We have two namespaces to deal > >>>>>>>with -- the network and the mount namespace. With nfs client code, > >>>>>>>everything is keyed off of the net namespace. That's not really the > >>>>>>>case here since we have to deal with a local fs tree as well. > >>>>>>> > >>>>>>>When an nfsd running in a container receives an RPC, how does it > >>>>>>>determine what mount namespace it should do its operations in? > >>>>>>> > >>>>>> > >>>>>>We don't use mount namespaces, so that's why I wasn't thinking about it... > >>>>>>But if we have 2 types of namespaces, then we have to tie mount namesapce to > >>>>>>network. I.e we can get desired mount namespace from per-net NFSd data. > >>>>>> > >>>>> > >>>>>One thing that Bruce mentioned to me privately is that we could plan to > >>>>>use whatever mount namespace mountd is using within a particular net > >>>>>namespace. That makes some sense since mountd is the final arbiter of > >>>>>who gets access to what. > >>>>> > >>>> > >>>>Could you, please, give some examples? I don't get the idea. > >>>> > >>> > >>>When nfsd gets an RPC call, it needs to decide in what mount namespace > >>>to do the fs operations. How do we decide this? > >>> > >>>Bruce's thought was to look at what mount namespace rpc.mountd is using > >>>and use that, but now that I consider it, it's a bit of a chicken and > >>>egg problem really... nfsd talks to mountd via files in /proc/net/rpc/. > >>>In order to talk to the right mountd, might you need to know what mount > >>>namespace it's operating in? > >>> > >> > >>Not really... /proc itself depens on pid namespace. /proc/net > >>depends on current (!) network namespace. So we can't just lookup > >>for this dentry. > >> > >>But, in spite of nfsd works in initial (init_net and friends) > >>environment, we can get network namespace from RPC request. Having > >>this, we can easily get desired proc entry (proc_net_rpc in > >>sunrpc_net). So it looks like we can actually don't care about mount > >>namespaces - we have our own back door. > > > >OK, good, that's what I was hoping for. Then we call up to whatever > >mountd is running in our network namespace, and for path lookups it's > >whatever fs namespace that mountd is running in that's going to matter. > > > > The problem here, is that mountd is running in pid namespace - not net. Every process runs in some pid namespace, and in some net namespace, so I don't understand what you mean by that. > What would happen, if we will have situation like below: > > mountd A mountd B > > pid_ns pid_ns > | | > mnt_ns mnt_ns > | | > ----- net_ns ---- > > Is it possible, BTW? > It yes, that is such construction valid? Looks like a mess, no. I'd expect there to be only one rpc.mountd running per network namespace. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
