pipe(2): Restore kevent EVFILT_READ/WRITE success on wrong pipe end.
Missed a spot when gathering the hunks in the previous change for
this.
PR kern/60851: change in pipe kevent EVFILT_READ/WRITE on wrong end
Revert "pipe(2): Add memory safety diagnostics."
This was rather sloppily done (from my local tree, not cleaned up
before committing in haste in an attempt to help diagnose the spate
of crashes that have been seen today). Will redo this a little more
tidily.
PR kern/59056: poll POLLHUP bugs
pipe(2): Plug mutex_obj leak.
This was introduced in what was supposed to be mere refactoring in
rev. 1.170 (pipe(2): Split new function pipefree out of pipeclose.) as
part of
PR kern/59056: poll POLLHUP bugs
I missed a spot, the mutex_obj_free in pipeclose, which should have
been moved into pipefree.
Noticed by mlelstv@.
pipe(2): Restore kevent EVFILT_READ/WRITE success on wrong pipe end.
In rev. 1.174, while cleaning up various issues in select/poll/kqueue
logic for pipes, I changed the behaviour of kevent when adding an
EVFILT_READ event for the write side of a pipe, or an EVFILT_WRITE
event for the read side of a pipe, to fail with EINVAL; previously it
would quietly be accepted and do nothing, which struck me, without much
thought, as uncontroversially wrong and unhelpful. But apparently
that's what FreeBSD and OpenBSD do too, and it seems that applications
such as mail/dovecot2 rely on it. So put it back.
PR kern/60851: change in pipe kevent EVFILT_READ/WRITE on wrong end
cpuctl(8): update Transmeta identification for Efficeon (TM8000 series).
It uses family 15 and it has a new way to decode processor revision, so update
family > 6 default to "Efficeon" and call transmeta_cpu_info() for it.
Decode processor revision from leaf leaf 0x80860002 EAX
when leaf 0x80860001 EBX contains 0x02000000.
Untested on the actual hardware (I don't have one).
Verified by the CPUID dump available online.
PR port-mips/60780 UBSan: long int << fix (src/common/lib/libc/string/memset2.c)
The comments say that memword_t is intended to be unsigned, but
presume that __register_t will provide that attribute. It usually
doesn't, so we need an unsigned type for building the fill value.
Thanks to Alexander Schreiber for running the UBSan built system
and reporting this (and others), and hopefully, in advance for
testing that this one is now fixed.
XXX - pullup -11 -10 (probably, it cannot possibly hurt)
End libc Makefile .${PARSEDIR} abuse
It is pointless assigning ${.PARSEDIR) to a variable using '='
as when that variable is later expanded, ${.PARSEDIR} will not
have a value, and we end up with things like:
.... -I. -I/home/source/ab/HEAD/src/lib/libc/arch/mips/softfloat
-I -DSOFTFLOAT_FOR_GCC
-I/home/source/ab/HEAD/src/lib/libc/arch/mips/softfloat
-I -DSOFTFLOAT_FOR_GCC
-DSOFTFLOAT -I/home/source/ab/HEAD/src/sys ....
That exxtracted from a failing command from the autobuilds (which I
first saw on my local system attempting a mips64eb build). That is
all part of one (long) command line from which I extracted that piece
(and then manually line wrapped it for this log message).
Note the 2nd and 4 lines ... those are meant to have ${.PARSEDIR}
between the -I and -D (I doubt there is a "./-DSOFTFLOAT_FOR_GCC"
[12 lines not shown]
gtmr: simplify the checking of the parent device properties.
The code still looks for the "physical" property on the device and the
parent device, but it's more obvious now.
Fix a whitespace issue in the process.
etc/etc.evbarm/Makefile.inc: follow-on hash generation fix
Revs. 141 & 142 introduced a guard that tried to prevent checksum
consolidation from running in contexts where there's nothing to process
-- that is, images aren't created at all. However, it then also
prevented clean builds that do include images from consolidating their
checksums as intended, since the "exists" check that was added reflects
too early a file system state on clean builds ("gzimg" doesn't exist
yet). It also didn't address the fact that there can be targets that
do in fact create and populate a "gzimg" directory, yet don't actually
generate any images as presently construed/defined are relevant for
hash generation, as happens with the evbearmv4-el arch.
Another fix for PR install/59195. Tested with earmv5hf (no images, no
"gzimg" directory created), evbearmv4-el (no images, "gzimg" directory
is created), and aarch64 (images and "gzimg" directory are created),
with clean builds into new directory structures and subsequent update
builds tested for each arch.
