vnode refcnt bug?
John E Hein
jhein at timing.com
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 salmon.maths.tcd.ie>, Ian Dowse writes:
> > In message <200311252003.hAPK3Bb9017036 at 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
More information about the freebsd-fs
mailing list