From owner-freebsd-fs@FreeBSD.ORG  Sat Apr 21 02:09:16 2007
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
X-Original-To: freebsd-fs@FreeBSD.org
Delivered-To: freebsd-fs@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 22BB716A402;
	Sat, 21 Apr 2007 02:09:16 +0000 (UTC)
	(envelope-from sobomax@sippysoft.com)
Received: from sippysoft.com (gk.360sip.com [72.236.70.226])
	by mx1.freebsd.org (Postfix) with ESMTP id DD03913C459;
	Sat, 21 Apr 2007 02:09:15 +0000 (UTC)
	(envelope-from sobomax@sippysoft.com)
Received: from [192.168.1.47] ([204.244.149.125]) (authenticated bits=0)
	by sippysoft.com (8.13.8/8.13.8) with ESMTP id l3L1pjCg067120
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Apr 2007 18:51:51 -0700 (PDT)
	(envelope-from sobomax@sippysoft.com)
Message-ID: <46296DE1.4090408@sippysoft.com>
Date: Fri, 20 Apr 2007 18:50:25 -0700
From: Maxim Sobolev <sobomax@sippysoft.com>
Organization: Sippy Software
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: "current@freebsd.org" <current@FreeBSD.org>, freebsd-fs@FreeBSD.org
Content-Type: text/plain; charset=KOI8-U; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Bug in the unmounting code
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Apr 2007 02:09:16 -0000

Hi,

I have noticed that there is a bug in unmounting code which could make 
filesystem unmountable when its parent filesystem has been forcefully 
unmounted. Following is quick way to reproduce the problem:

[sobomax@pioneer ~]$ sudo mkdir -p /tmp/1/2
[sobomax@pioneer ~]$ sudo mkdir /tmp/3
[sobomax@pioneer ~]$ sudo mount_nullfs /tmp/1 /tmp/3
[sobomax@pioneer ~]$ sudo mount_nullfs /tmp/1 /tmp/3/2
[sobomax@pioneer ~]$ sudo umount -f /tmp/3
[sobomax@pioneer ~]$ sudo mount -v
/tmp/1 on /tmp/3/2 (nullfs, local, fsid 03ff000202000000)
[sobomax@pioneer ~]$ sudo umount 03ff000202000000
umount: unmount of /tmp/3/2 failed: No such file or directory
umount: retrying using path instead of file system ID
umount: unmount of /tmp/3/2 failed: No such file or directory

Investigation has revealed that in this case vn_lock() call fails with 
ENOENT due to the following piece of code:

vn_lock()
[...]
                 if (error == 0 && vp->v_iflag & VI_DOOMED &&
                     (flags & LK_RETRY) == 0) {
                         VOP_UNLOCK(vp, 0, td);
                         error = ENOENT;
                         break;
                 }
[...]

Addition of LK_RETRY flag fixed the problem, but my knowledge of VFS is 
quite limited so that I would appreciate if somebody could verify that 
the fix below won't have any undesirable effects.

-Maxim

--- vfs_mount.c 2007/04/21 01:40:53     1.1
+++ vfs_mount.c 2007/04/21 01:41:09
@@ -1155,7 +1155,7 @@
                 mnt_gen_r = mp->mnt_gen;
                 VI_LOCK(coveredvp);
                 vholdl(coveredvp);
-               error = vn_lock(coveredvp, LK_EXCLUSIVE | LK_INTERLOCK, td);
+               error = vn_lock(coveredvp, LK_EXCLUSIVE | LK_INTERLOCK | 
LK_RETRY, td);
                 vdrop(coveredvp);
                 /*
                  * Check for mp being unmounted while waiting for the