vnode refcnt bug?
ezk at cs.sunysb.edu
Wed Nov 26 10:35:26 PST 2003
In message <200311261013.aa21508 at salmon.maths.tcd.ie>, Ian Dowse writes:
> In message <200311252357.hAPNvlGs021309 at agora.fsl.cs.sunysb.edu>, Erez Zadok wr
> >If you have a cwd on a lower mnt pt before the mount, I'd say it makes
> >_some_ sense to move it "up" to the mnt pt (root vnode) of the newly mounted
> >fs. This could be very useful for, say, a login shell.
> >I say "some" b/c I'm concerned about the possibility that some bad process
> >(rm -rf) that is just started in an emoty mnt point, all of sudden is moved
> >up to a vnode full of real files, and that process may happily go on to
> >delete the files in the newly mounted f/s.
> >Doing the reverse upon unmount (moving the cwd from upper to lower) sounds
> >even stranger to me. Why? B/c the process used to see some files and now
> >it sees none. Where did it all go? This can break applications in all
> >sorts of unhappy ways.
> Whether or not checkdirs() is retained, I think it is just good
> practice to undo at unmount time anything that was done when the
> filesystem was mounted. An obvious case is if you accidentally mount
> a file system in the wrong place or make the common mistake of
> typing "mount -a" when there are NFS entries in fstab that are
> already mounted. Without the unmount-time checkdirs call, this is
> an operation that cannot be undone because any processes that had
> a cwd of the covered vnode before the mount will lose their cwd
> entirely if you unmount it.
If you accidentally mount something in the wrong place, you should be able
to umount it quickly thereafter; the chance that some new process comes
along and "sits" on your cwd is rather rare. And if it happens, you can
lsof and kill it, then umount just fine.
I don't understand why would a "mount -a" re-mount existing stuff like
already-mounted NFS volumes? Does it? It shouldn't IMHO.
I agree w/ you that umount should undo anything that a mount did, but I
think you may be allowing a mount to proceed in cases that it shouldn't have
succeeded; so you first "get yourself in trouble" and then try to find a way
to undo it. :-)
> There were also some obscure cases involving booting frem CD and
> then mounting the real root filesystem directly over /. If you
> unmount it later, all processes would lose their fd_rdir references
> to /, so they suddenly become chrooted into a dead vnode even though
> their original root directory on the CD root still exists.
OK, but "obscure cases" shouldn't IMHO change default common behavior. Make
the default case the more common one, the one that will be used by most
users. You went ahead and changed important behavior for a minority of
> Anyway, I think the best solution for now is to make the checkdirs()
> at unmount time conditional on the MNT_FORCE flag. This should fix
> amd's EBUSY detection while still making it possible to fully undo
> the effects of a mount operation. The change is fairly trivial, so
> I'll see if I can get something committed before 5.2 is released.
Thanks. That'd help. I would also hope that the existing cwd-migrating
behavior will become the one that someone has to trigger using MNT_FORCE;
that is, please make the default behavior be the old behavior (EBUSY and
such). Anyone who really wants the new behavior should use MNT_FORCE (I
assume there's a flag for it in umount(8) also.)
More information about the freebsd-fs