DCACHE_DISCONNECTED use in try_to_ascend/d_kill

I've been trying to figure out if we can pare down DCACHE_DISCONNECTED uses to only those required by exportfs, and ran across this one.

Is there another test that would work instead?

(E.g., checking list_empty(&dentry->d_u.d_child)?)

--b.

commit c83ce989cb5ff86575821992ea82c4df5c388ebc

Author: Trond Myklebust <[email protected]>
Date:   Tue Mar 15 13:36:43 2011 -0400

VFS: Fix the nfs sillyrename regression in kernel 2.6.38

The new vfs locking scheme introduced in 2.6.38 breaks NFS sillyrename because the latter relies on being able to determine the parent directory of the dentry in the ->iput() callback in order to send the appropriate unlink rpc call.

Looking at the code that cares about races with dput(), there doesn't seem to be anything that specifically uses d_parent as a test for whether or not there is a race:
- __d_lookup_rcu(), __d_lookup() all test for d_hashed() after d_parent
- shrink_dcache_for_umount() is safe since nothing else can rearrange the dentries in that super block.
- have_submount(), select_parent() and d_genocide() can test for a deletion if we set the DCACHE_DISCONNECTED flag when the dentry is removed from the parent's d_subdirs list.

create helper function for duplicated functionality" )

index 361882a..a39fe47 100644
@@ -296,8 +296,12 @@ static struct dentry *d_kill(struct dentry *dentry, struct dentry *parent)
 	__releases(parent->d_lock)
 	__releases(dentry->d_inode->i_lock)
 {
-	dentry->d_parent = NULL;
 	list_del(&dentry->d_u.d_child);
+	/*
+	 * Inform try_to_ascend() that we are no longer attached to the
+	 * dentry tree
+	 */
+	dentry->d_flags |= DCACHE_DISCONNECTED;
 	if (parent)
 		spin_unlock(&parent->d_lock);
 	dentry_iput(dentry);

@@ -1030,6 +1034,7 @@ static struct dentry *try_to_ascend(struct dentry *old, int locked, unsigned seq
 	 * or deletion
 	 */
 	if (new != old->d_parent ||
+		 (old->d_flags & DCACHE_DISCONNECTED) ||
 		 (!locked && read_seqretry(&rename_lock, seq))) {
 		spin_unlock(&new->d_lock);
 		new = NULL;

There's also one DCACHE_DISCONNECTED use in fs/nfs/dir.c that I was hoping could be eliminated. It was added by Al with d9e80b7de91db05c1c4d2e5ebbfd70b3b3ba0e0f. It looks totally theoretical to me (nfs isn't exportable, hence shouldn't see DCACHE_DISCONNECTED dentries), but maybe I'm missing something.

At a minimum maybe we could pull a comment out of Al's commit?:

--b.

index f430057..b96c687 100644
@@ -1194,6 +1194,12 @@ out_zap_parent:
 		/* If we have submounts, don't unhash ! */
 		if (have_submounts(dentry))
 			goto out_valid;
+		/*
+		 * We can't d_drop the root of a disconnected tree:
+		 * its d_hash is on the s_anon list and d_drop() would hide
+		 * it from shrink_dcache_for_unmount(), leading to busy
+		 * inodes on unmount and further oopses.
+		 */
 		if (dentry->d_flags & DCACHE_DISCONNECTED)
 			goto out_valid;
 		shrink_dcache_parent(dentry);

Ignore me, I'm confused: there's a different use of DCACHE_DISCONECTED here (for v2/v3 root dentries that we expect may one day be hooked into a parent we find someplace else?). It looks to me like it clashes with nfsd/exportfs's use. I'm not sure what to do about that.

--b.