1. When consolidating entropy from per-CPU pools, drop the amount
pending to zero; otherwise the entropy consolidation thread might
keep consolidating every second.
This uncovered a feedback loop with kern.entropy.depletion=1 and
on-demand entropy sources, which is that depleting the pool and then
requesting more from it causes the on-demand entropy sources to
trigger reseed, which causes cprng_fast/strong to request more which
depletes the pool again which causes on-demand entropy sources to
trigger reseed, and so on.
To work around this:
2. Set a rate limit on reseeding (advancing the entropy epoch) when
kern.entropy.depletion=1; otherwise reseeding gets into a feedback
loop when there are on-demand entropy sources like RDRAND/RDSEED.
(By default, kern.entropy.depletion=0, so this mainly only affects
systems where you're simulating what happens when /dev/random blocks
for testing.)
xpmap_ptom_unmap() doens't need to be called at splvm; we own the pa.
Use atomic ops to change pmap_pa_end
Make sure the ptom/mtop are up to date before giving the pages back to the
pool.
We try to avoid counting the seed file's entropy twice, e.g. once
from the boot loader and once from rndctl via /etc/rc.d/random_seed.
But previously, if you had a /var/db/entropy-file that was deemed to
have zero entropy, that would prevent rndctl -L from _ever_ setting a
nonzero entropy estimate, even if you (say) copy a seed file over
from another machine (over a non-eavesdroppable medium) and try to
load it in with rndctl -L, e.g. via `/etc/rc.d/random_seed start'.
Now we accept the first _nonzero_ entropy estimate from a seed file.
The operator can still always trick the kernel into believing there's
entropy in the system by writing data to /dev/random, if the operator
knows something the kernel doesn't; this only affects the _automated_
seed file loading.
On the hacky benchmarks I have, held over from the transition to 1:1
threading, this restores pthread_cond_signal() perf to radixtree/sleepq
levels, and semes much better than either with pthread_cond_broadcast() and
10 threads. It would be interesting to see what might be achieved with a
lockless lookup, which is within grasp now thanks to pid_table being used
for lookup.
cpu_intr_p() is broken on amiga, fix it.
From code inspection it looks like amiga and other m68k ports check for ASTs
with interrupts enabled in some cases, which is racy. Not fixed.
when relocating, to make sure the section we're accessing is mappable.
Currently this check fails, because of the Xen section, which has RELAs but
is an unmappable unallocated note.
Also improve the prekern ASSERTs while here.
Bar size is probed writing 0xffffffff to the BAR and reading back; but while
doing this the decoding address is not guaranteed to be valid and could have
side effect.
Xen PVH enforces disabling decoding before writing to a BAR.
Proposed on tech-kern@, got positive comments
Invokes all on-demand RNG sources. This enables HWRNG driver
developers to use a dtrace probe on rnd_add_data to examine the data
coming out of the HWRNG:
dtrace -n 'fbt::rnd_add_data:entry /args[0]->name == "amdccp0"/ {
...examine buffer args[1] length args[2]...
}'
This corrects an issue where if the start and end address fall in different
lines, and the end address is not cache line size aligned, the last line
will not be invalidated properly.
Patch from compiler-rt upstream: https://reviews.llvm.org/rCRT323315
in xennet_ioctl(), so just do splnet() like other drivers do, and hope for best
fixes failed KASSERT() e.g. when starting rpcbind(), which ends
up calling this via sys_setsockopt()->sosetopt()->...->in6_addmulti()->
if_mcast_op(), this path doesn't currently take IFNET_LOCK()
C99 initializers would have been nice, but part of the struct is
explicit parameters and part of the struct is implicit state, and
-Wmissing-field-initializers can't discriminate between them
(although for some reason it doesn't always fire!).
Instead, just do:
struct timedwaitclock T;
timedwaitclock_setup(&T, timeout, clockid, flags, epsilon);
while (...) {
error = timedwaitclock_begin(&T, &timo);
if (error)
...
error = waitwhatever(timo);
timedwaitclock_end(&T);
...
}
use PHYSDEVOP_map_pirq to get the pirq/gsi for MSI/MSI-X, switch also INTx
to use it instead of PHYSDEVOP_alloc_irq_vector
MSI confirmed working with single-vector MSI for wm(4), ahcisata(4), bge(4)
XXX added some provision for MSI-X, but it doesn't actually work (no interrupts
delivered), needs some further investigation; disable MSI-X for XENPV
via flag in x86/pci/pci_machdep.c
Candidate fix for:
panic: lock error: Mutex: mutex_vector_enter,542: locking against myself: lock 0xffff8f611abd37e0 cpu 8 lwp 0xffff8f60a3c6a040
cpu8: Begin traceback...
vpanic() at netbsd:vpanic+0x178
snprintf() at netbsd:snprintf
lockdebug_abort() at netbsd:lockdebug_abort+0xe6
mutex_vector_enter() at netbsd:mutex_vector_enter+0x3c1
ksem_close_fop() at netbsd:ksem_close_fop+0x17
closef() at netbsd:closef+0x69
fd_free() at netbsd:fd_free+0x101
exit1() at netbsd:exit1+0x118
sys_exit() at netbsd:sys_exit+0x3d
syscall() at netbsd:syscall+0x299
Would be nice to have an automatic test for this. Since semids are
only 24 bits, we only need to create a few thousand of them to have a
high probability of collision. Maybe we should bump default semmax
while here...
8bpp Xorg wsfb server and mlterm-wscons (formerly mlterm-fb) work.
No particular comment on port-hp300@ and port-hppa@:
https://mail-index.netbsd.org/port-hp300/2020/05/02/msg000170.html
Special thanks to Miod Vallat, for his advice about HP-UX implementation
and binutils patches to disassemble old HP-UX a.out-hp300hpux binaries
(and also contributing his 425e back in 2014).
macallan