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. --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
