vnode refcnt bug?

John E Hein jhein at
Tue Nov 25 21:00:00 PST 2003

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 at>, Ian Dowse writes:
 > > In message <200311252003.hAPK3Bb9017036 at>, 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

More information about the freebsd-fs mailing list