From owner-freebsd-fs@FreeBSD.ORG Tue Nov 25 13:07:34 2003 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1362316A4CE for ; Tue, 25 Nov 2003 13:07:34 -0800 (PST) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 9DF7043F93 for ; Tue, 25 Nov 2003 13:07:30 -0800 (PST) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 25 Nov 2003 21:07:29 +0000 (GMT) To: Erez Zadok In-Reply-To: Your message of "Tue, 25 Nov 2003 15:03:11 EST." <200311252003.hAPK3Bb9017036@agora.fsl.cs.sunysb.edu> Date: Tue, 25 Nov 2003 21:07:29 +0000 From: Ian Dowse Message-ID: <200311252107.aa96370@salmon.maths.tcd.ie> cc: fs@freebsd.org Subject: Re: vnode refcnt bug? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2003 21:07:34 -0000 In message <200311252003.hAPK3Bb9017036@agora.fsl.cs.sunysb.edu>, Erez Zadok wr ites: >Please see this short thread of discussion on amd-dev. I've included two >messages from this thread. It suggests that fbsd5 may have a vnode refcount >bug (a vnode isn't held where it should). > >I've not personally investigated this bug. Does anyone on fs@ has come >across such a possible bug? Hmm, I guess it is caused by checkdirs() in vfs_mount.c moving the process cwd to the underlying vnode before attempting the unmount. Does this only happen if the cwd is at the mount point itself? When a file system is first mounted, checkdirs() looks for processes that had a cwd or chroot set to the vnode that is about to be covered. It moves these processes to the new mountpoint vnode. This behaviour goes back a long time (I'm not sure what the reasons were), but it had the problem that you would get a "Device busy" error if you attempted to unmount the file system later, and a forced unmount would leave the process with a stale cwd or chroot vnode (i.e. "mount /mnt; umount /mnt" would fail if any processes previously had a cwd of /mnt, and "mount /mnt; umount -f /mnt" would cause such processes to lose their reference to the /mnt directory). More recently (Feb 2001), I changed unmount to undo the checkdirs() step so that processes with a cwd or chroot at the mount point get moved back to the covered vnode before the unmount is attempted. This fixes the two issues, but it has the side-effect that if the only vnode references to a file system are processes whose cwd or chroot directory is on the mountpoint, then the unmount will succeed, and those processes will be moved to the underlying directory. The reference count checks could be moved to before checkdirs(), but I think there are cases where the current behaviour is preferable, so maybe it needs to be an unmount() flag... BTW, does amd delete the mountpoint directory after the unmount? That would explain why the directory goes away entirely. Ian