WARNING: at fs/dcache.c:2630 prepend_path+0x1eb/0x200()

[Jeff Layton <jlayton@redhat.com>]

Over the last several year or so, we've gotten several reports of this sort
of warning message popping up:

[34011.669912] ------------[ cut here ]------------
[34011.670473] WARNING: at fs/dcache.c:2630 prepend_path+0x1eb/0x200()
[34011.671198] Hardware name: Bochs
[34011.671564] Root dentry has weird name <>  vfsmnt: fs:nfs4
[34011.672195] Modules linked in: nfsv4 auth_rpcgss nfs lockd sunrpc dns_resolver fscache kvm_amd kvm microcode virtio_net virtio_balloon i2c_piix4 cirrus drm_kms_helper ttm virtio_blk drm i2c_core
[34011.674464] Pid: 7470, comm: ls Tainted: G        W    3.7.0-6.fc19.x86_64 #1
[34011.675417] Call Trace:
[34011.675712]  [<ffffffff8106892f>] warn_slowpath_common+0x7f/0xc0
[34011.676404]  [<ffffffff81068a26>] warn_slowpath_fmt+0x46/0x50
[34011.677058]  [<ffffffff8109eb24>] ? lg_local_lock+0x44/0x80
[34011.677675]  [<ffffffff811e8f18>] ? prepend_path+0x38/0x200
[34011.678315]  [<ffffffff811e90cb>] prepend_path+0x1eb/0x200
[34011.678926]  [<ffffffff811e913c>] path_with_deleted+0x5c/0xa0
[34011.679578]  [<ffffffff811e976f>] d_path+0xbf/0x100
[34011.680139]  [<ffffffff81244bb5>] proc_pid_readlink+0x95/0x100
[34011.680783]  [<ffffffff811d8509>] sys_readlinkat+0xa9/0xc0
[34011.681418]  [<ffffffff81104a5c>] ? __audit_syscall_entry+0xcc/0x300
[34011.682144]  [<ffffffff811d853b>] sys_readlink+0x1b/0x20
[34011.682740]  [<ffffffff816fbd19>] system_call_fastpath+0x16/0x1b
[34011.683425] ---[ end trace 5e8c789abf4f6e53 ]---

This warning was added in commit 98dc568bc.

I've found a way to trigger this at will:

Mount up a nfs mount and cd into it from a shell. Do a lazy umount of
the mount, and then do this from the shell:

    $ ls -l /proc/self/cwd

That will cause that warning message to fire. The mnt will be detached
and will look like the global root, but the d_name.name will be a
zero-length string.

I'm pretty sure there are other ways to trigger this too -- maybe
involving races with shrinkable mounts (not sure on this).

My initial thought was to add "(unreachable)" to the string, a'la
d_path_with_unreachable(), but the changelog on commit 7b2a69ba70 made
me think that that's not such a good idea.

Given that this is fairly easy to reproduce, is there any point in
keeping this warning around or should we just remove it?
-- 
Jeff Layton <jlayton@redhat.com>