On Tue, Jun 17, 2008 at 05:34:47PM -0400, Trond Myklebust wrote: > On Tue, 2008-06-17 at 16:51 -0400, J. Bruce Fields wrote: > > On Sat, Jun 14, 2008 at 02:16:27PM -0400, Trond Myklebust wrote: > > > On Sat, 2008-06-14 at 13:45 -0400, J. Bruce Fields wrote: > > > > > NACK. I deliberately ripped out the old struct gss_auth spinlock in > > > > > order to allow multiple gss_auth per inode (I believe Kevin was asking > > > > > for this). > > > > > > > > OK, makes sense. So what will be the scope of a cred lookup--an rpc > > > > client? > > > > > > That should normally be the case, but why do you need to change the > > > locking here in the first place? Is there ever going to be a case where > > > the same rpc_cred has upcalls on several different pipes? I can't see > > > how that could be justified. > > > > If you allow changing the upcall version over the life of the kernel, > > then it's difficult to avoid. You can insist that noone have both the > > new and old version opened simultaneously, for example, but it's harder > > to know when there are no longer messages sitting around that have been > > unhashed but are still lying around waiting for a process to wake up and > > examine their results. > > AFAIK, there are two cases when the dying rpc.gssd closes the pipe: > > 1. gss_cred->gc_upcall is set. In this case, the gss_cred has a > full reference to the gss_msg, so it has no trouble locating the > message and figuring out if it needs to resend (rpc_purge_list() > will ensure that the error field is set to EAGAIN) or if the > call completed before gssd died. If you are worried about the > fact that gss_upcall_callback uses gss_msg->auth to access the > inode in order to do the locking, then just add a pointer to the > inode to gss_msg: it is not as if a gss_msg can migrate from one > upcall queue to another. > 2. gss_cred->gc_upcall is not set. In this case the call to > rpc_purge_list() in rpc_pipe_release() will ensure that the > message gets immediately released. > > In other words, I can't see that keeping the current behaviour will > cause you to have more than one upcall at a time even if you do restart > rpc.gssd. Yeah, I think that's more or less exactly the sort of case I was worried about--so let me see if that does the job. Thanks!--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
