Namespacing afs and AF_RXRPC

[David Howells]

Hi Eric, Al,

I'm thinking about how to namespace the in-kernel AFS client and AF_RXRPC.
It's not completely trivial, however.

For the AFS client, I think the way to namespace it is:

 (1) Manual mounts are in the fs and net namespace of the parent process.

 (2) Automounts inherit the parent vfsmount's net namespace.  I'm not sure
     about fs namespace.

 (3) Mounts in the same net namespace can share:

	- A cache manager
	- Cell list
	- DNS lookup cache

     Mounts in different net namespaces would require a different cache
     manager running on a different port.

 (4) Two mounts with different net namespaces accessing the same volume *have*
     to have different superblocks - even if they're in the same fs namespace
     - because we don't want to end up playing callback ping pong between
     sockets.

I'm not sure how to link AFS's information to the net namespace.  Would I have
to add a pointer to struct net to say, a struct netns_afs?  It might be
possible to combine this with AF_RXRPC and have a struct netns_rxrpc, but I'm
unsure as to whether that makes sense.

Also, this brings into question namespacing key lookups as the DNS service in
the kernel is accessed through request_key() - but they need to be done in the
appropriate net namespace.


For AF_RXRPC, new sockets would pick up the parent's net namespace - but
there's a potential problem: AF_RXRPC will be used for tools that manage the
AFS filesystem.  Some commands can be implemented by asking the kernel to do
operations on our behalf, but not necessary all.  However, we might be in a
separate namespace to the AFS mount that we're looking at, so if we open an
AF_RXRPC socket, it may be directed differently than operations we do on the
filesystem.

Maybe that's just something to mark as 'don't do that then'.  If you set up
your container that way, you're asking for trouble for the occupants.


Anyway, there's a variety of global information in AF_RXRPC that would need
moving into a namespace:

    - Peer records.
    - Rx epoch (appears in packet headers).
    - Service connection list.
    - Connection list for procfs.
    - Call list for procfs.
    - Local endpoints list.

I think /proc/net/rxrpc_* would have to return just what's in the caller's net
namespace - which might mean you won't see things your filesystem has access
to because that's in a different namespace.

I think the client connection lists have to stay global because (a) we
maintain a global IDR of client connections to facilitate fast lookup in the
UDP data_ready handler; (b) this manages the limitation on the number of
client connections.

David