check that the idle loop, soft interrupt handlers, workqueue, and xcall
callbacks do not modify the preemption count, in most cases, knowing it
should be 0 currently.
this work was originally done by simonb. cleaned up slightly and some
minor enhancement made by myself, and with discussion with riastradh@.
other callback call sites could check this as well (such as MD interrupt
handlers, or really anything that includes a callback registration. x86
version to be commited separately.)
This causes a leak of l_nopreempt in xc_thread when a CPU is offlined
and onlined again, because the offlining heartbeat_suspend and the
onlining heartbeat_resume happen in separate xcalls.
No change to callers because they are already bound to the CPU:
1. cnpollc does kpreempt_disable/enable itself around the calls to
heartbeat_suspend/resume anyway
2. cpu_xc_offline/online run in the xcall thread, which is always
bound to the CPU that is being offlined or onlined
for standard one - refuse EVFILT_WRITE if the reader is already disconnected
fixes test failure for kernel/kqueue/write/t_pipe.c on PIPE_SOCKETPAIR kernel
PR kern/55690
passed when called via pipe2(2), fixing repeatable process hang during
compilation with 'gcc -pipe'
refactor fsocreate() to return the new socket and file pointers,
expect the caller to call fd_affix() once initialization is fully complete
use the new fsocreate() to replace the duplicate open-coded 'flags' handling
in makesocket() used for socketpair(2), and in the PIPE_SOCKETPAIR pipe1()
this also fixes lib/libc/sys/t_pipe2 pipe2_cloexec test to succeed
on PIPE_SOCKETPAIR kernel
fixes PR kern/55690
Lock as writer on establish/disestablish and as reader on list traverse.
For exechook ride "exec_lock" as it is already take as reader when
traversing the list. Add local locks for exithook and forkhook.
Move exec_init before signal_init as signal_init calls exechook_establish()
that needs "exec_lock".
PR kern/39913 "exec, fork, exit hooks need locking"
netinet6/nd6 from the kernel. Now, the minimal compat code can
be successfully loaded and unloaded along with the rest of the
COMPAT_90 code.
XXX pullup-10 - hopefully before RC2
be used VERY early in boot; such consumers statically allocate the vmem
arena and boundary tags, and then explicitly add those static, private
boundary tags to the arena tag free list using the new function vmem_add_bts().
Vmem arenas that use private boundary tags will NOT consume the statically
allocated bootstrap tags used by the vmem system itself; the assumption is
that the consumer of such an arena knows what they're doing, and is responsible
for all necessary resource management. A macro, VMEM_EST_BTCOUNT(), is
provided to help such consumers size the static boundary tag store based
on the expected number of spans and early allocations. Once the private
tags are exhausted, the arena will dynamically allocate tags as usual.
from an arena. This is just a convenience wrapper around vmem_xalloc(),
that's just a bit more obvious how to use and performs some additional
sanity checks.
From OpenBSD:
commit 7b4d35e0a60ba1dd4daf4b1c2932020a22463a89
Author: bluhm <bluhm@openbsd.org>
Date: Fri Oct 20 16:25:15 2023 +0000
Avoid assertion failure when splitting mbuf cluster.
m_split() calls m_align() to initialize the data pointer of newly
allocated mbuf. If the new mbuf will be converted to a cluster,
this is not necessary. If additionally the new mbuf is larger than
MLEN, this can lead to a panic.
Only call m_align() when a valid m_data is needed. This is the
case if we do not refecence the existing cluster, but memcpy() the
data into the new mbuf.
Reported-by: syzbot+0e6817f5877926f0e96a@syzkaller.appspotmail.com
OK claudio@ deraadt@
The issue is harmless if DIAGNOSTIC is not enabled.
XXX pullup-10
XXX pullup-9
kpause(9) forbids zero.
Local workaround for wider problem in PR kern/57718, to address
immediate symptom of crash on any system with hz=50, e.g. alpha in
qemu:
panic: kernel diagnostic assertion "timo != 0 || intr" failed: file "/usr/src/sys/kern/kern_synch.c", line 249
XXX pullup-10
XXX pullup-9
XXX pullup-8
Unfortunately, owing to PR kern/57705 and PR misc/57706, it isn't
convenient to flip the xfail switch on a test for this bug. So we'll
do that separately. (But I did verify that a rumpified version of
the test postd to PR kern/57703 failed without this change, and
passed with this change.)
PR kern/57703
XXX pullup-10
andvar