Re: [PATCH 1/1] nfslock01.sh: Don't test on NFS v3 on TCP

[Nikita Yushchenko <nikita.yoush@cogentembedded.com>]

>> The overall picture is:
>>
>> - by design, filesystem namespaces and network namespaces are independent, it is pretty ok for two
>> processes to share filesystem namespace and be in different network namespaces, or vice versa.
>>
>> - the code in question, while being in the kernel for ages, is breaking this basic design, by using
>> filesystem path to contact a network service,
> 
> Not just in the kernel, but also in user-space.  The kernel contacts
> rpcbind to find how to talk to statd.  statd talks to rpcbind to tell it
> how it where it can be reached.

AFAIR the badness happens when in-kernel nfsd registers itself in rpcbind, using AF_LOCAL to contact it. 
When nfsd is started for a child network namespace, it immediately breaks nfsd running in the root 
network namespace, because ports used by the later get overwritten inside rpcbind and become no longer 
available for local or remote clients.

I'd say it is userspace responsibility to make entire setup consistent against the used namespaces, but 
it is kernel responsibility to keep namespaces isolation while executing individual operations. In the 
case of registering in-kernel nfsd being started, using namespace-safe way to do it looks more important 
for me than the reasoning outlined in commit 7402ab19cdd5 ("SUNRPC: Use AF_LOCAL for rpcbind upcalls") 
that you mention.

And, this won't be fixed by trying to an abstract AF_LOCAL socket before using a filepath-bound one, 
since if one is not available, the nfsd running in the root namespace will still get broken by starting 
nfsd in a child namespace.

Maybe, the way used to reach rpcbind to register in-kernel services shall be special cased.

Nikita