From patchwork Tue Feb 12 00:38:13 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: NeilBrown X-Patchwork-Id: 2126631 Return-Path: X-Original-To: patchwork-linux-nfs@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id 566013FCA4 for ; Tue, 12 Feb 2013 00:38:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760964Ab3BLAi2 (ORCPT ); Mon, 11 Feb 2013 19:38:28 -0500 Received: from cantor2.suse.de ([195.135.220.15]:55976 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760951Ab3BLAi2 (ORCPT ); Mon, 11 Feb 2013 19:38:28 -0500 Received: from relay1.suse.de (unknown [195.135.220.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 5DA42A4C0E; Tue, 12 Feb 2013 01:38:25 +0100 (CET) Date: Tue, 12 Feb 2013 11:38:13 +1100 From: NeilBrown To: "Myklebust, Trond" , Alexander Viro Cc: NFS Subject: More fun with unmounting ESTALE directories. Message-ID: <20130212113813.427b8e05@notabene.brown> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-suse-linux-gnu) Mime-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org I've been exploring difficulties with unmounting stale directories and discovered another bug. If I: SERVER: mkdir /foo/bar #and make sure it is exported CLIENT: mount -o vers=4 server:/foo/bar /mnt SERVER: rm -r /foo CLIENT: > /mnt/baz # gets an error of course CLIENT: ls -l /mnt # error again CLIENT: umount /mnt The result of that last command is: /mnt was not found in /proc/mounts /mnt was not found in /proc/mounts Strange? cat /proc/mounts ..... 10.0.2.2://foo/bar /mnt\040(deleted) nfs4 rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.2.15,minorversion=0,local_lock=none,addr=10.0.2.2 0 0 .... Notice the "\040(deleted)". NFS has unhashed that directory because it is obviously bad, and d_path() notices and adds " (deleted)". Now I might be able to argue that NFS shouldn't be unhashing a directory that is a mountpoint - it certainly seems strange behaviour. But I think I can more strongly argue that /proc/mounts shouldn't be showing the mounted directory, but instead the directory that it is mounted on. Obviously these both have the same name so it shouldn't matter ... except that here is a case where it does. I "fixed" it with though I suspect that isn't safe and needs some locking. Probably both should be fixed: NFS should not invalidate any mounted directory, and show_vfsmnt() should report the mointpoint, not the mounted directory. I can't figure out any way to get NFS to not invalidate the mounted directory. I think it happens in nfs_lookup_revalidate() when it calls d_drop(), but I don't know how to tell if a given dentry is a mnt_root for any mountpoint. Suggestions? Thoughts? Thanks, NeilBrown --- a/fs/proc_namespace.c +++ b/fs/proc_namespace.c @@ -93,7 +93,7 @@ static int show_vfsmnt(struct seq_file *m, struct vfsmount *mnt) { struct mount *r = real_mount(mnt); int err = 0; - struct path mnt_path = { .dentry = mnt->mnt_root, .mnt = mnt }; + struct path mnt_path = { .dentry = r->mnt_mountpoint, .mnt = &(r->mnt_parent)->mnt }; struct super_block *sb = mnt_path.dentry->d_sb; if (sb->s_op->show_devname) {