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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
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?

--
Best regards,
Stanislav Kinsbursky
--
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


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux