Re: synchronous AF_LOCAL connect

[Simo Sorce <simo@redhat.com>]

On Wed, 2013-02-20 at 17:27 +0000, Myklebust, Trond wrote:
> On Wed, 2013-02-20 at 12:04 -0500, Chuck Lever wrote:
> 
> > Yes, but AF_LOCAL is supposed to be a generic transport for RPC.  This is not a feature we just made up, it's actually a well-defined API that exists on other platforms (it's even specified in RFCs).  Right now I would hesitate to restrict the use of AF_LOCAL upcalls to only synchronous contexts, because eventually we may want to use the transport in asynchronous contexts.
> 
> The whole problem is that it is a piss-poorly defined feature in an
> asynchronous kernel context.
> 
> Sockets carry around a well defined net namespace context that allow
> them to resolve IP addresses. However they carry none of the file
> namespace context information that is required to make sense of AF_LOCAL
> "addresses".
> 
> IOW we have 3 options:
> 
>      1. Drop AF_LOCAL support altogether
>      2. Add file namespace context to the RPC or socket layers
>      3. Drop asynchronous support, so that we have a reliable
>         userspace-defined context.
> 
> 1) involves a user space api change, which will bring down the iron fist
> of the Finn.
> 2) involves cooperation from the VFS and socket folks which doesn't seem
> to be happening.
> 
> so that leaves (3), which is perfectly doable since we do _not_ want to
> expose the rpc layer to anything outside the kernel. It's not intended
> as a generic libtirpc...
> 
> > If we were to go with using a synchronous connect, however, I think there should be some kind of safety check to make sure the xs connect function is not being invoked from an asynchronous context.  This is a restriction that does not exist for other transports supported by the kernel RPC client, so it should be underscored in the code.
> 
> void xs_connect_local(struct rpc_task *task)
> {
> 	if (RPC_IS_ASYNC(task))
> 		rpc_exit(task, -ENOTCONN);
> .....
> }
> 
> ...done.
> 

This seems the most reasonable approach to me too, and makes the code
simpler for now.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York