On Wed, Feb 20, 2013 at 11:20:05AM -0500, Chuck Lever wrote: > > On Feb 20, 2013, at 11:03 AM, J. Bruce Fields <bfields@xxxxxxxxxxxx> > wrote: > > > On Wed, Feb 20, 2013 at 10:56:54AM -0500, Chuck Lever wrote: > >> > >> On Feb 20, 2013, at 10:47 AM, "J. Bruce Fields" > >> <bfields@xxxxxxxxxxxx> wrote: > >> > >>> On Mon, Feb 18, 2013 at 05:54:25PM -0500, bfields wrote: > >>>> The rpc code expects all connects to be done asynchronously by a > >>>> workqueue. But that doesn't seem necessary in the AF_LOCAL case. > >>>> The only user (rpcbind) actually wants the connect done in the > >>>> context of a process with the right namespace. (And that will be > >>>> true of gss proxy too, which also wants to use AF_LOCAL.) > >>>> > >>>> But maybe I'm missing something. > >>>> > >>>> Also, I haven't really tried to understand this code--I just > >>>> assumed I could basically call xs_local_setup_socket from ->setup > >>>> instead of the workqueue, and that seems to work based on a very > >>>> superficial test. At a minimum I guess the PF_FSTRANS fiddling > >>>> shouldn't be there. > >>> > >>> Here it is with that and the other extraneous xprt stuff gone. > >>> > >>> See any problem with doing this? > >> > >> Nothing is screaming at me. As long as an AF_LOCAL connect > >> operation doesn't ever sleep, this should be safe, I think. > > > > I'm sure it must sleep. Why would that make any difference? > > As I understand it, sometimes an ASYNC RPC task is driving the > connect, and such a task must never sleep when calling outside of > rpciod. AF_LOCAL is currently only used to register rpc services. I can't see any case when it's called asynchronously. (And the same will be true of the gss-proxy calls, which also plan to use AF_LOCAL.) > rpciod must be allowed to put that task on a wait queue and > go do other work if the connect operation doesn't succeed immediately, > otherwise all ASYNC RPC operations hang (or worse, an oops occurs). > > >> How did you test it? > > > > I'm just doing my usual set of connectathon runs, and assuming mounts > > would fail if the server's rpcbind registration failed. > > Have you tried killing rpcbind first to see how the error cases are handled? No, thanks for the suggestion, I'll check. > Does rpcbind get the registration's "owner" field correct when > namespaces are involved? Looking at rpcb_clnt.c.... I only ever see r_owner set to "" or "0". I can't see why that would need to change in a container. --b. -- 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
