Re: [PATCH][RFC] nfsd/lockd: have locks_in_grace take a sb arg

["J. Bruce Fields" <bfields@fieldses.org>]

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.

--b.