Comment 70 for bug 769927

(In reply to comment #17)
> FWIW, I did some more testing yesterday. I did the reproducer on a kernel both
> with and without commit 36d43a437, and used crash to look at the d_count after
> triggering the mount and before the unmount. Those counts were the same in both
> cases -- the mnt_root had a d_count of 2, and s_root a d_count of 1.

That makes sense, since s_root won't be used in path lookups
and then mnt_root will have one for when it was d_alloc()ed and
one from the umount code (I think).

>
> Perhaps I should do it again and have a look at the d_flags, or just get the
> entire dentry structs in both cases so we can compare them.

I think we are most interested in the mnt_root dentry because
it is the one assigned to the vfsmount struct and so will be
the one involved in path walks. I think s_root is tucked away
in the super block and is basically inert in the NFS case.

What I don't get is whether the oops occurs from the fist call
to shrink_dcache_for_umount_subtree() or not. If it does then
I'd be wondering how the anonymous dentry got into the tree
under s_root at all (although that itself deserves more
looking around in the code).

The other thing that bugs me is in __d_drop() where we have:

if dentry is hashed then
  if dentry is disconnected
    remove from appropriate list
  else
    remove from other appropriate list
    maybe block on rcuwalk barrier
  done
done

So we don't boot active rcu-walk walks when dropping the
anonymous dentry, if it even gets to the drop that is.