On Fri, 2008-02-22 at 11:31 +1100, Neil Brown wrote: > On Thursday February 21, [EMAIL PROTECTED] wrote: > > > > On Thu, 2008-02-21 at 15:58 +1100, Neil Brown wrote: > > > > > My question is: *why* cannot rpc_shutdown_client complete until all > > > active rpc_tasks complete? The use of reference counting ensure that > > > once they do all complete, the client will be finally released and any > > > relevant modules will also be released. > > > > > > Is there really any need to wait for completion? > > > > Looking at the code, I suspect that you can probably get rid of the > > rpc_shutdown_client() without creating too much trouble (since we now > > hold a reference to the vfsmount in most of the asynchronous > > operations). > > > > However the asynchronous sillyrenames are still a problem: if you don't > > wait for the sillyrename RPC call to complete, then you end up with the > > famous "Self-destruct in 5 seconds" message on umount (because we have > > to hold a reference to the directory inode for the duration of the RPC > > call if we want to avoid lookup races and cache consistency issues > > during normal operation). > > Could the sillyrename call hold a reference to the vfsmount???
That would require a VFS change to allow the ->rename() and ->unlink() inode ops to pass down the vfsmount to the filesystem. Unfortunately Al and Christoph have both NACKed such a change. SteveD's fix was therefore the only thing we could do in this situation. - To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
