to prevent a crash when attempting rename("/", "foo"). This is not really
what I want going forward and it may cause e.g. rmdir("blah/") to fail, so
if it causes trouble for anyone back it out. The right fix is going to have
to wait until the qemu/tcp_vtw problems I ran into last night get sorted out.
reversing the sense of the associated test and using the big block I
moved a couple versions back (and didn't reindent on purpose) as the
body of the if statement.
There are now no gotos in namei_oneroot, only normal loop logic.
now be changed to a loop break and another null test and goto outside
the loop. In neither of the other two cases for exiting the loop can
foundobj be null.
has an unconditional loop break at the end this can be done safely,
now that the other loop break has been patched out.
Add a spurious set of braces to preserve the indent for the moment.
continue.
This runs the "are we mounted?" test on every directory instead of
only sometimes; however, it's not exactly an expensive test (null
pointer check) and the prior logic wasn't exactly sensible -- it
checked at the beginning and after following a symlink but, for some
reason, not after crossing a mount point.
namei_follow() randomly drops foundobj on success. Do that in the
caller instead. On the other hand, the caller was updating cn_nameptr,
and since that's closely related to the buffer manipulation in
namei_follow, do that there.
Remove state->lookup_alldone. Don't need it any more; it's set
precisely when succeeding with a null result vnode and it now works to
just check for that case.
(also, when "error" is already 0 we don't need to assign another 0 to
it, even as a precaution.)
Fix lookup_for_nfsd_index() -- it wasn't locking the directory it was
searching. I'm not sure if this is something I introduced or if it's
just been wrong for ages; the code path is used only for serving
index.html in WebNFS and probably just ought to be removed.
In the test where we check if searchdir is NULL and fail if we needed
to return ni_dvp, also check if searchdir is on a different volume
from foundobj. I believe the NULL test was meant to encompass this
situation, but it definitely doesn't in some cases related to
emulroots. This appears to be a bug, and I'm pretty sure it's not one
I introduced.
(The search directory and result are on different volumes if we
crossed a mount point.)
