How implementation details become ABI: a case study

Nope - in that case there are 3 or 4 dentries involved (depending on whether /tmp is a mountpoint). There's root directory of root filesystem. Name's empty, parent - itself. There's /tmp on root filesystem. Name being "tmp", parent - root of root filesystem. There's (possibly) root directory of whatever is mounted on /tmp. Again, name is empty, parent - itself. And there's /tmp/foo - name is "foo", parent - /tmp on root fs or root of filesystem mounted on /tmp. And it's unhashed since that rename.

We start with that dentry and vfsmount of either root fs or that mounted on /tmp and walk towards root. When we reach the root of current vfsmount we just proceed to dentry and vfsmount of mountpoint and continue from there. When we reach the process' root (sensu chroot(2)) or global root (vfsmount that isn't mounted on anything) we stop.

In this case the names we see along the way are "foo" and "tmp", and or dentry is unhashed, so d_path() produces "/tmp/foo (deleted)". And that's what readlink() on these guys returns. See fs/dcache.c:d_path() and the stuff next to it.

The name of dentry is just a single pathname component. That "/tmp/foo (deleted)" isn't stored anywhere - it's calculated on demand.