We had a bug report recently where someone was complaining about silly-renamed files being left around: https://bugzilla.redhat.com/show_bug.cgi?id=511901 ...they attached a reproducer to the bug which involves a pthreads-based program killing a child thread that's unlinking and closing a file. The unlink triggers a sillyrename (since the file is still open). The parent kills the child thread and if timed just right, the child thread will be killed after the RENAME call is issued but before the reply is processed. The file will end up renamed on the server, but the client won't be aware of it and won't unlink it during dentry_iput. It's a bit of work, but the best way I can envision to fix this would be to make sillyrename do an asynchronous RENAME call, and have it wait for the reply. If the task is killed, then the RENAME can proceed and the file would be unlinked when the dput is done by the rpc_release call. At this point, I just want to know whether this approach is acceptable before I spend time on it. Is there a better way to handle this? Thanks, -- 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
