From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: WARNING: at fs/dcache.c:2630 prepend_path+0x1eb/0x200() Date: Thu, 10 Jan 2013 08:59:05 -0500 Message-ID: <20130110085905.07c1ab47@corrin.poochiereds.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Miklos Szeredi , linux-fsdevel@vger.kernel.org To: Al Viro Return-path: Received: from mx1.redhat.com ([209.132.183.28]:34238 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751260Ab3AJN7J (ORCPT ); Thu, 10 Jan 2013 08:59:09 -0500 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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] [] warn_slowpath_common+0x7f/0xc0 [34011.676404] [] warn_slowpath_fmt+0x46/0x50 [34011.677058] [] ? lg_local_lock+0x44/0x80 [34011.677675] [] ? prepend_path+0x38/0x200 [34011.678315] [] prepend_path+0x1eb/0x200 [34011.678926] [] path_with_deleted+0x5c/0xa0 [34011.679578] [] d_path+0xbf/0x100 [34011.680139] [] proc_pid_readlink+0x95/0x100 [34011.680783] [] sys_readlinkat+0xa9/0xc0 [34011.681418] [] ? __audit_syscall_entry+0xcc/0x300 [34011.682144] [] sys_readlink+0x1b/0x20 [34011.682740] [] 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