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.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
--
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
