>> Now, how do I plan to solve the rpc_get_mount problem. Some time ago >> there was similar problem with the devpts filesystem - people making >> ptys work per-container tried to solve the same problem and they >> ended up (with Al's help) with a yet another devpts mount option which >> explicitly stated that a new instance should be created. How do you >> think if we do the same for rpc_pipefs (a newinstance mount option) and >> add yet another mount option for its only client (nfs) telling it where >> to look for the rpc mount for (e.g. rpcmount=/var/...) ? > > As long as we have some mechanism to ensure that rpc.gssd from one net > namespace doesn't try to establish a kerberos security context on behalf > of a NFS mount that resides in a different net namespace. > My point is if the rpc.gssd resides in a different net namespace, then > we have no guarantee that the IP address we pass in the upcall even > points to the same server, so we must ensure that the namespaces match. Sure, but for doing so there's no need in strict aliasing rpcpipefs-s super blocks with struct net. By strict I mean, that not only the superblock knows which struct net it works with, but also a struct net references rpcpipefs-s supers. >>> 3) Convert the nfs_client and superblock to be per-net namespace >> >> Ack about the nfs_client, but as far as the superblock is >> concerned - I think we should tag only the nfs_server with >> net for the same reasons as in the item 2) above. > > You should tag the nfs_server, and then make sure that nfs_compare_super > does not match something that is tagged with a different net namespace > than the current one. Otherwise, you can end up mounting the wrong NFS > server (for the same reason as above). Yes, of course. >>> 4) Convert lockd's struct host to be per-net namespace > > Cheers > Trond > > -- 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
