[PATCH] nfs_unlink() problem fix

When foo is unlinked, nfs_unlink() does a sillyrename, this puts the
dentry on nfs_delete_queue, and (in the VFS) unhashes it from the
dcache.  This causes problems, since any later access to the
silly-renamed new .nfs file will create a NEW dentry that aliases the
one we originally created, but unhashed.

This causes various confusion, especially if we want to try to delete it
again later.

So fix this by not unhash the dentry after silly-renaming.  In 2.2, each
fs was responsible for doing a d_delete(), in 2.4 and later it happens
in the VFS layer and I think it was just an oversight that the 2.4 VFS
doesn't consider sillyrename (considering the code and comments that are
cruft).

Also fixed up some comments while debugging this.

fs/namei.c

@@ -1631,7 +1631,9 @@ int vfs_unlink(struct inode *dir, struct dentry *dentry)
 			error = dir->i_op->unlink(dir, dentry);
 	}
 	up(&dentry->d_inode->i_sem);
-	if (!error) {
+
+	/* We don't d_delete() NFS sillyrenamed files--they still exist. */
+	if (!error && !(dentry->d_flags & DCACHE_NFSFS_RENAMED)) {
 		d_delete(dentry);
 		inode_dir_notify(dir, DN_DELETE);
 	}

fs/nfs/unlink.c

@@ -150,8 +150,7 @@ nfs_async_unlink_release(struct rpc_task *task)
 
 /**
  * nfs_async_unlink - asynchronous unlinking of a file
- * @dir: directory in which the file resides.
- * @name: name of the file to unlink.
+ * @dentry: dentry to unlink
  */
 int
 nfs_async_unlink(struct dentry *dentry)
@@ -190,7 +189,7 @@ nfs_async_unlink(struct dentry *dentry)
 }
 
 /**
- * nfs_complete_remove - Initialize completion of the sillydelete
+ * nfs_complete_unlink - Initialize completion of the sillydelete
  * @dentry: dentry to delete
  *
  * Since we're most likely to be called by dentry_iput(), we