From patchwork Mon Jan 21 02:48:59 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: NeilBrown X-Patchwork-Id: 2009191 Return-Path: X-Original-To: patchwork-linux-nfs@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id 36EB5DF264 for ; Mon, 21 Jan 2013 02:49:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752568Ab3AUCtQ (ORCPT ); Sun, 20 Jan 2013 21:49:16 -0500 Received: from cantor2.suse.de ([195.135.220.15]:45566 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752543Ab3AUCtP (ORCPT ); Sun, 20 Jan 2013 21:49:15 -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 46A64A398E; Mon, 21 Jan 2013 03:49:14 +0100 (CET) Date: Mon, 21 Jan 2013 13:48:59 +1100 From: NeilBrown To: "Myklebust, Trond" , Alexander Viro Cc: NFS Subject: NFSv4 cannot unmount ESTALE directories (in some cases). Message-ID: <20130121134859.24fbd103@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 If you use NFSv4 to "mount server:/foo/bar /mnt", then "rm -r" /foo/bar on the server, then accesses to /mnt will naturally return ESTALE. Unfortunately "umount /mnt" will also return ESTALE and leave the stale directory mounted. Adding "-l" or "-f" to "umount" doesn't help. The problem is that nfs_lookup_revalidate fails. As the mountpoint is never not accessed by a lookup (after the initial mount) it seems a bit pointless calling d_revalidate in this case ... by maybe not. I can make the problem go away by testing for LOOKUP_JUMP and having nfs_lookup_revalidate never fail if that flag it set (for a directory). The resulting patch is: --- fs/nfs/dir.c | 7 +++++++ 1 file changed, 7 insertions(+) However I cannot easily tell if this is an elegant solution of an ugly hack, and am hoping that someone who understands revalidation and LOOKUP_JUMPED better than I (who only discovered the latter today) could provide advice. Al? Trond? Should I make this into a formal patch submission, or is there a better way? Thanks, NeilBrown --- linux-3.0-SLE11-SP2.orig/fs/nfs/dir.c +++ linux-3.0-SLE11-SP2/fs/nfs/dir.c @@ -1183,6 +1183,13 @@ out_zap_parent: goto out_valid; if (dentry->d_flags & DCACHE_DISCONNECTED) goto out_valid; + if (flags & LOOKUP_JUMPED) + /* Didn't use a name to get here, so saying + * the name is invalid is pointless. + * This allows "umount" to succeed on a + * STALE mountpoint. + */ + goto out_valid; shrink_dcache_parent(dentry); } d_drop(dentry);