On Wed, 10 Dec 2008 11:31:36 -0500 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Wed, Dec 10, 2008 at 11:25:06AM -0500, Jeff Layton wrote: > > It works. With a nfs-utils that has your patches to properly set the > > cache timeouts it looks like this problem is generally fixed. The module > > refcounts go back to normal once the tickets expire. > > > > That said, I think we should have a look at Bruce's suggestion for changing > > the way that the module refcounts are actually handled. It would seem to > > make more sense to hold the reference based on the exports using that auth > > scheme, and to purge the caches on module unload. > > > > Not a huge deal, but probably something we should consider. > > Yeah. Since I don't care enough about module unloading, I'm not going > to work on this now. But it's unfortunate. > > I'm a little more worried about why the RPC_GSS_PROC_DESTROY requests > aren't working. > I took some time today to dig into this. Here's some debug output from the RPC_GSS_PROC_DESTROY request on the client: RPC: 0 holding RPCSEC_GSS cred ffff880011579bb8 RPC: new task initialized, procpid 2846 RPC: allocated task ffff88001e110000 RPC: 11 __rpc_execute flags=0x281 RPC: 11 call_start nfs4 proc NULL (async) RPC: 11 call_reserve (status 0) RPC: 11 call_refresh (status 0) RPC: 11 refreshing RPCSEC_GSS cred ffff880011579bb8 RPC: 11 call_refreshresult (status -13) RPC: 11 return 0, status -13 RPC: 11 release task RPC: 11 releasing RPCSEC_GSS cred ffff880011579bb8 ...looks like we're trying to refresh the credentials before sending the call but that's failing. That's as far as I've gotten with it so far though. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
