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.
Prefer using ${.PARSEDIR} over assuming that ${.CURDIR} is src/lib/libc.
Mostly this changes ${.CURDIR} refs into either ${.PARSEDIR}, ${LIBCDIR},
or ${NETBSDSRCDIR} refs.
Set LIBCDIR earlier to ensure it's available always.
This will be used to build a smaller libc (eg, with no assert strings.)
Tested builds on atari, x86-64, arm64, and vax.
Yet another printf format fix...
Use PRI[diuoxX]PTR for [u]intptr_t types rather than PRId64.
Pointers (and hence [u]intptr_t's) are not 64 bits in ILP32 systems.
I picked 'x', well, just because ...
And this time I verified it builds on i386!
Fix wacky printf usage - hopefully unbreak 32 bit builds
Rather than converting an int type to a (void *) and then
printing using %p (one presumes to obtain hex), use the PRIx64
(the value is int64_t) macro (just like previous output lines do)
instead. (Use the '#' printf flag as well, to get the 0x when
needed, and just 0 if the value is 0).
As it was, 32 bit builds would complain about converting between
a pointer and an integer of a different size - converting it to
intptr_t before void * would have fixed that, but would lose the
top 32 bits of the value on 32 bit systems.
kqueue/kernel/t_pipe: Fix newly failing test.
If the read side of a pipe has been closed, then for the write side:
- poll will set POLLOUT, not POLLNVAL (nor fail with EBADF), and
- select will report writable, not fail with EBADF,
because the write side is immediately writable and will fail with
EPIPE/SIGPIPE -- it won't block if you try to write.
So surely kqueue with EVFILT_WRITE should simply report immediately
writable too, not fail with EBADF. And that is what I caused to
happen by simplifying and clarifying the code and fixing various edge
cases. (The bad response that this test was added to check is a
kernel crash on null pointer dereference; that, fortunately, has not
regressed.)
PR kern/59056: poll POLLHUP bugs
pipe(2): Don't cv_wait_sig in a loop without breaking on signal.
If a signal does arrive, it will turn into a busy wait! Not helpful.
But this wait should be limited to scheduling delays for other
threads anyway, not for general I/O, so there's no need to be
interruptible by a signal.
Prompted by:
PR kern/59056: poll POLLHUP bugs
pipe(2): Restructure select/poll/kqueue records.
1. When a thread is waiting on an endpoint of a pipe, have it wait on
_that endpoint_ (i.e., cv_wait or selrecord), not on the other
endpoint sometimes depending on the direction of the I/O.
2. Make poll(2) on the writer side of a pipe wake with POLLERR when
the reader side is closed, because write would return immediately,
and fail with EPIPE/SIGPIPE. See also:
https://mail-index.NetBSD.org/tech-kern/2026/09/21/msg031255.html
(In contrast, for the other way around, when the writer side of a
pipe is closed, poll(2) on the reader is already defined to wake
with POLLHUP, and while read would return immediately, it will not
_fail_; it will simply report EOF, so there is no justification
for POLLERR in that direction.)
3. For EVFILT_READ, require the reader side of a pipe; likewise, for
[6 lines not shown]
pipe(2): Simplify PIPE_RESTART handling.
Now that it applies to each side independently, we can just make it
final, because new I/O operations are not allowed on an file that has
had its .fo_restart called. Makes reasoning about all this easier.
XXX Consider renaming PIPE_RESTART to PIPE_CLOSING: the .fo_restart
operation means the file is irreversibly destined to be closed soon
and just needs any pending I/O on it to be interrupted and fail
promptly so we can finally close the file.
Preparation for:
PR kern/59056: poll POLLHUP bugs
pipe(2): Make pipe sides a little more symmetric.
1. When reading from or writing to a pipe, busy _this side_ of the
pipe, not the other side.
2. In pipeclose, all operations on _this side_ of the pipe have already
quiesced. But operations on the other side may not have. So wait
for the _other side_ to be unbusied before disconnecting the peer
(changing ppipe->pipe_peer from pipe to NULL).
With (1) and (2) we can prove a simple property that makes reasoning
about this code easier: If a pipe is busy, its peer pointer is stable
even across cv_wait on the pipe lock. Without these changes I'm not
sure I could prove that property (though I haven't exhibited a
reproducer for any issues arising from its failure).
3. Make write wait on wpipe->pipe_wcv, and make read wait on
rpipe->pipe_rcv, consistently, so that any waiters on one side of a
pipe will always be waiting on one of _that side's_ condvars.
[17 lines not shown]
pipe(2): Fix wakeup of pending writers on close of write side.
The job of pipe_restart is to wake any pending I/O operations on the
file when it is about to be closed. New references cannot be taken
for new I/O operations; once all existing references are drained, the
system calls pipe_close.
What pipe_restart did was to wake pipe->pipe_rcv and pipe->pipe_wcv.
But the condvars of _which pipe_?
After renaming the variables to match reality, it becomes clear that
wpipe->pipe_wcv and wpipe->pipe_rcv are never used -- instead,
pipe_read waits for rpipe->pipe_rcv, and pipe_write waits for
rpipe->pipe_wcv. So pipe_restart on the write side of a pipe woke
wpipe->pipe_rcv and wpipe->pipe_wcv, which nothing was waiting for,
and failed to wake rpipe->pipe_rcv or rpipe->pipe_wcv.
(Perhaps we should just have a single struct pipe::pipe_cv member,
and have pipe_read use rpipe->pipe_cv and pipe_write use
[4 lines not shown]
pipe(2): Split new function pipefree out of pipeclose.
Makes it easier to reason about pipeclose this way.
Prompted by:
PR kern/59056: poll POLLHUP bugs
pipe(2): Rename pipe variables to make more sense.
- wpipe for the writer side of a pipe, associated with a file open
for FWRITE.
- rpipe for the writer side of a pipe, associated with a file open
for FREAD.
- pipe for either side of the pipe.
- ppipe for the peer corresponding to pipe.
No functional change intended.
Prompted by trying to wrap my head around this pipe(2) code in order
to address:
PR kern/59056: poll POLLHUP bugs
mips: mask interrupts during context switch to preserve curlwp/sp invariants
Interrupts are masked until MIPS_CURLWP, SP, and this CPU's
ci_curlwp all refer to the new LWP in both cpu_switchto and
softint_fast_dispatch
gcc: backend: Sprinkle -O1 to some files for alpha
With this workaround, more than 270 pkgsrc's successfully build for me.
PR toolchain/60843 GCC/alpha 14 miscompiles GCC backend
heimdal: Apply upstream fix for kill(2) argument order in kdc(8).
commit b22f33250a98efcda3a07fdc36bc2fd386230857
Author: Roland C. Dowdeswell <elric at imrryr.org>
Date: Fri Sep 25 14:45:23 2026 +0100
kdc: correct kill_kids kill(2) arg order
PR bin/60841: kdc(8) sends pids to signals instead of signals to pids
