for openat() and friends) to ni_atdir to avoid confusion with a
previously existing (and, alas, still documented) ni_startdir field
that meant something else entirely.
- Move the namecache's hash computation to inside the namecache code,
instead of being spread out all over the place. Remove cn_hash from
struct componentname and delete all uses of it.
- It is no longer necessary (if it ever was) for cache_lookup and
cache_lookup_raw to clear MAKEENTRY from cnp->cn_flags for the cases
that cache_enter already checks for.
- Rearrange the interface of cache_lookup (and cache_lookup_raw) to
make it somewhat simpler, to exclude certain nonexistent error
conditions, and (most importantly) to make it not require write access
to cnp->cn_flags.
This change requires a kernel bump.
stale value can be returned and this causes a diagnostic panic in
namei.
In relookup(), clear *vpp before calling VOP_LOOKUP, as is done in
lookup_once(), as an additional precautionary measure.
(in theory both of these fixes are not required together)
Should fix PR 47040.
by calling NDAT(&nd, dirvp) after NDINIT().
Right now the implementation is vile and unspeakable to avoid changing
the kernel ABI; this way we can get openat() and friends into 6.1. I
will rectify the mess and bump the kernel once things are working.
when crossing a mount point, don't keep the parent vnode locked.
ie. don't lock a vnode while holding another vnode which belongs to a
different filesystem. otherwise we propagate slowness (or deadness) of a
filesystem to another via vnode lock chain.
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.)
