Revert the supporting logic in -r1.190 of vfs_lookup.c, and fix the
important change to set searchdir = NULL instead of searchdir =
foundobj. Then supply the necessary new supporting logic to cope with
some new cases where searchdir can be null.
This is at the point when lookup_once crosses a mountpoint going down;
the idea was to avoid coupling locks across filesystems as that has a
number of potentially negative consequences. At this stage of namei,
though, it's important to set searchdir to null as this is what is
used later on to handle other cases arising from crossing mount
points. If you set it to be the same as foundobj, that instead creates
the impression that you looked up "/." on the new volume, and that
causes odd things to happen in corner cases such as the one appearing
in PR 47040.
This fix ought to be pulled up to -6 and -7, and it probably could be
safely, but given the delicacy of this code and the fact that it's
taken me more than three years to find the combination of time and
intestinal fortitude to do it, as well as the minor nature of the
resulting wrong behavior observed so far, I think we'll let that part
go.
This change also exposes an annoying corner case: if you cross a mount
point and the root directory vnode of the new volume is not a
directory but a symlink, we now have no searchdir to follow the
symlink relative to. In principle one could hang onto the searchdir
from before calling lookup_once and use that, or complexify the
interface of lookup_once to hang onto it as desired for this case.
Alternatively one could add the necessary null checks to namei_follow
and allow only absolute symlinks in this case, as for an absolute
symlink one doesn't need the old searchdir. However, given that only
broken filesystems have symlinks as their root vnodes, I'm not going
to bother. Instead if this happens we'll just fail with ENOTDIR.
* Delete the stubs of the XK_EXE mechanism that was never implemented.
From a security, stability, and simplicity perspective, i would
consider implementing it a truly terrible idea, so let's better
get rid of it.
* Do not use the local variable "num" in el_wgets() alternately for
two completely different purposes. Only use it for the number
of characters read, as stated in the comment (or -1 as long as
that number is still unknown), not for the (more or less boolean)
return value of read_getcmd(). Actually, there is no need at
all to save the latter return value after testing it once.
* The function read_getcmd() has very unusual return values:
It returns -1 for success and 0 for EOF/error. Switch that around
to 0 for success and -1 for EOF/error to be less confusing, and
get rid of the OKCMD preprocessor macro.
* Get rid of one #ifdef section in el_wgets() by using
el->el_chared.c_macro directly at the only place
where it is used.
* Delete the unused MIN() macro.
- The file tokenizer.c no longer uses chartype.h,
so don't include the header.
- The dummy definitions of ct_{de,en}code_string() for the
NARROWCHAR case are only used in history.c, so move them there.
- Now the whole content of chartype.h is for the wide character
case only. So remove the NARROWCHAR ifdef and include the
header only in the wide character case.
- In chartype.h, move ct_encode_char() below the comment explaining it.
- No more need for underscores before ct_{de,en}code_string().
- Make the conversion buffer resize functions private.
They are only called from the decoding and encoding functions
inside chartype.c, and no need can possibly arise to call them
from anywhere else.
Man page says <sys/param.h>, but that's wrong.
The real problem was that rump didn't have splraiseipl at all, and
that already got fixed before I woke up this morning and panicked
because I had obviously broken all the builds!
This does have an effect -- it nullifies the next pointer. (The text
was copied from PSLIST_DESTROY, which really has no effect without
options DIAGNOSTIC.)
