On Wed, 2013-02-20 at 12:39 -0500, Chuck Lever wrote:
> On Feb 20, 2013, at 12:27 PM, "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> 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".
>
> I recognize this problem, but I fail to see how it is connected to asynchronicity in general. The issue seems to be specifically how rpciod implements asynchronicity.
The problem is connected to asynchronicity in general because there is
no userspace context to fall back on. Asynchronous contexts are pretty
much by definition required to drop their connection to the original
context in order to be useful.
As for adding more userspace context information to rpciod, I refuse
point blank to even start that discussion until someone has a valid use
case.
> > 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.
>
> The problem with 1) is that rpcbind uses a special feature of AF_LOCAL to protect registrations from being removed by a malicious or ignorant registrant. That's why I added AF_LOCAL. Somehow we would have to replace that feature.
>
> > 2) involves cooperation from the VFS and socket folks which doesn't seem
> > to be happening.
>
> Yep, I'm aware of that.
>
> > 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...
>
> I hoped for a better alternative, but I see that folks do not have the patience for that. ;-)
>
> >
> >> 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.
>
> That's what I had in mind. I might even add a WARN_ON_ONCE().
>
--
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
