Re: [PATCH 0/9] sunrpc: Start making sunrpc work in containers

[Pavel Emelyanov <xemul@parallels.com>]

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