vnode refcnt bug?

[Erez Zadok]

In message <200311252338.aa05451 at salmon.maths.tcd.ie>, Ian Dowse writes:
> In message <200311252122.hAPLMRfE018534 at agora.fsl.cs.sunysb.edu>, Erez Zadok wr
> ites:
> >Hmmm, yes I think that could be a serious problem (esp. since fbsd doesn't
> >have autofs yet).  And I think it deviates from "norms" where a cwd is
> >essentially occupying a vnode within the mounted f/s and therefore the f/s
> >shouldn't be unmounted!  This is rather bad for users who sit on an nfs mnt
> >point, ls'ing files happily, and then the kernel unmounts the mnt pt, moves
> >their cwd down to the covered (typically empty) vnode, and the poor user's
> >next /bin/ls shows nothing.
> 
> Yes, I agree completely - however the question of what to do with
> references to about-to-be-covered vnodes at mount time still remains.
> I'll have to look in more detail at why the checkdirs() approach
> was needed in the first place to see if simply removing it is an
> option.

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.

> Any other approaches I can think of right now for solving this issue
> appear to either extend the original checkdirs() hack, or else just
> replace one kind of undesirable behaviour with another.

My personal philosophy when it comes to a choice b/t several un/desirable
modes of operations is the following:

1. Offer flags/options/whatever for users to pick their desired behavior.

2. Don't break existing "expected" behavior: make that the default mode of
   operation.

3. In some cases, it's desirable to change the default behavior to one of
   the "new modes".  But at least everyone will have a way to get the
   behavior they want.

4. Disadvantage: poor programmers/maintainers have to keep several modes of
   operation working.

The above won't make everyone happy, but it'd maximize the percentage of
happy users.

> Ian

I guess we first need to find out what were the original reasons for the
change in fbsd.  Maybe we can find a way to accommodate the needs for that
change w/o breaking functionality.

Cheers,
Erez.