Date: Tue, 25 Nov 2003 21:59:41 -0700 From: John E Hein <jhein@timing.com> To: Erez Zadok <ezk@cs.sunysb.edu> Cc: fs@freebsd.org Subject: Re: vnode refcnt bug? Message-ID: <16324.13117.190129.769195@gromit.timing.com> In-Reply-To: <200311252122.hAPLMRfE018534@agora.fsl.cs.sunysb.edu> References: <200311252107.aa96370@salmon.maths.tcd.ie> <200311252122.hAPLMRfE018534@agora.fsl.cs.sunysb.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Erez Zadok wrote at 16:22 -0500 on Nov 25: > Ian, I'm CC-ing my reply to the am-utils developers mailing list, amd-dev. > Let's keep this thread on both fs@ and amd-dev for a bit. > > Can the people on amd-dev who noticed this problem please answer Ian's > questions? > > In message <200311252107.aa96370@salmon.maths.tcd.ie>, Ian Dowse writes: > > 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? Yes. It appears that's the case. I can force it to happen with amq -u. > > 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). No forced umount is necessary. It just gets unmounted after the amd timeout if you just sit at your shell prompt and wait (or amq -u). > > 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. > > If Amd created the mount point when it started (say, the mnt pt didn't > exist), then Amd will also try to rmdir it upon unmount. It gets unmounted first. Then within a minute, it gets deleted. ls returns nothing (but exit code is 0). pwd gives: pwd: .: No such file or directory
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16324.13117.190129.769195>