On Tue, Mar 18, 2008 at 07:27:34PM -0400, Trond Myklebust wrote: > > On Tue, 2008-03-18 at 18:32 -0400, J. Bruce Fields wrote: > > On Tue, Mar 18, 2008 at 06:15:15PM -0400, bfields wrote: > > > When an rpc client is shut down, gss destroy messages are sent out > > > asynchronously, and nobody waits for them. > > > > > > If those rpc messages arrive after the client is completely shut down, I > > > assume they just get dropped by the networking code? Is it possible for > > > them to arrive while we're still in the process of shutting down, and if > > > so, what makes this safe? > > > > In other words--when does the task that's created to send the destroy > > message get freed, and if that doesn't happen till after the rpc client > > and associated objects are freed, is there a risk of someone trying to > > access those objects through fields in that task? > > > > --b. > > Are you talking about the rpc_task? That gets destroyed in the normal > fashion, and since the collection of all rpc_tasks should hold a > reference to the rpc_client, there shouldn't normally be any ordering > problems there. Oh, OK, got it. Like Ogla says, we were getting oopses due to references to an rpc_stats structure that was freed on the assumption it was safe to do so after rpc_shutdown_client() returned. (In the case of the nfs client, the rpc_stats structure is declared statically. But isn't that memory freed when the module is removed?) --b. > > Note however that we do some magic in 'rpc_free_auth' to extend the > natural lifetime of the rpc_client beyond that of the NFS 'shutdown'. > > > > Olga's seeing some odd oopses on shutdown after testing our gss callback > > > code. And of course it's probably our callback patches at fault, but I > > > was starting to wonder if there was a problem with those destroy > > > messages arriving at the wrong moment. Any pointers welcomed. > > > > > > --b. > > Is the new code touching the destroy path? If so, how, and what are the > new assumptions that are being made? > > -- > 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
