ktrcsw(): should not be called when the thread is owning interlock or on sleepq
The issue is that for ktrcsw() we lock the ktrace_mtx mutex while owning
the interlock from a subsystem that called msleep(). In particular, the
VM subsystem might call msleep() if page allocation failed. This
establishes order VM locks (e.g. domain free queue lock) -> ktrace_mtx.
Calling free() while owning ktrace_mtx gives the reverse order.
Worse, msleep_spin_sbt() call s ktrcsw() while the thread is put on
sleep queue. Then, since the mutex might be contested, the thread needs
to be put on turnstil, which cannot work.
Move the ktrcsw() call for switch-out after the wakeup, when the thread
does not yet re-obtained any locks. From there, we call a special
version of ktrcsw(), which is passed the actual time when the context
switch occured.
The drawback is that the switch-out record is only written in the
ktrace.out file after the switch-in occurred, but this is probably not
[7 lines not shown]
release: Ship firmware from kmods repo on DVD
The packages for X.Y-RELEASE are a snapshot of the quarterly branch
for stable/X, i.e. typically built on X.(Y-1)-RELEASE. (The case of
Y=0 is an exception for obvious reasons.) This works for most ports
but not for kernel modules, which may need to be built on the release
in question; this is why we have a separate "kmods" repository.
Make sure that we put the packages from the kmods repository onto the
mini-pkg-repo on the DVD rather than shipping unusable firmware.
Reviewed by: bz
MFC after: 1 week
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D52581
arm64: Fix kernel panic in get_arm64_sve during core dump
The coredump logic calls get_arm64_sve twice: once to get the note size,
and once to get the data. The note size calculation depended on the
volatile `PCB_FP_SVEVALID` flag. If this flag was cleared between the
two calls (e.g., due to a context switch clearing the flag to comply
with the ABI), the second call would expect a smaller buffer size than
the first, triggering a KASSERT panic ("invalid size").
Fix this by ensuring the SVE state is saved to the PCB before we decide
whether to use SVE or VFP.
PR: 292195
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D54532
native-xtools: use static LLVM libraries
Set the MK_LLVM_LINK_STATIC_LIBRARIES knob to "yes" when building the
native-xtools target. This reverts to the behaviour prior to
2e47f35be5dc.
This avoids a build failure that occurs otherwise, where compilation
fails looking for a libllvmprivate.so that was not built.
It is unclear if this addresses the issue in all instances---some
replies in the PRs indicate otherwise. Still, some report success, and
in my own testing this fixed creation of a cross-compiled poudriere
jail. Commit this while we continue to investigate...
PR: 286710, 291409
Tested by: marck, rdunkle at smallcatbrain.com
Reviewed by: emaste
MFC after: 3 days
Fixes: 2e47f35be5dc ("Convert libllvm, libclang and liblldb into private shared libraries").
[4 lines not shown]
src.conf.5: Regen after addition of MK_SOUND
A description for WITHOUT_SOUND is still missing though.
(cherry picked from commit 3f2f3c52e6f192df435bdb5861018402ec1167d0)
Set virtual_oss_enable="NO" in /etc/defaults/rc.conf
This prevents 'service -e' from emitting (/var/log/messages):
/usr/sbin/service: WARNING: $virtual_oss_enable is not set properly - see rc.conf(5)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1987
Reviewed by: christos
Signed-off-by: eborisch at gmail.com
MFC after: 1 week
(cherry picked from commit 1b2d495a24c36d81b14178a2f898025946bff2d8)
bluetooth: Don't use a non-string to initialize NG_HCI_BDADDR_ANY
Explicitly use an array of 6 zeroes instead of a C string containing
nul characters. GCC 15 warns about the truncation, but this is
cleaner regardless.
In file included from /usr/obj/.../amd64.amd64/tmp/usr/include/bluetooth.h:51,
from usr.sbin/virtual_oss/virtual_bt_speaker/bt_speaker.c:45:
usr.sbin/virtual_oss/virtual_bt_speaker/bt_speaker.c: In function 'register_sdp':
usr.sbin/virtual_oss/virtual_bt_speaker/bt_speaker.c:96:13: error: initializer-string for array of 'unsigned char' truncates NUL terminator but destination lacks 'nonstring' attribute (7 chars into 6 available) [-Werror=unterminated-string-initialization]
96 | NG_HCI_BDADDR_ANY, (const uint8_t *)&record, sizeof(record),
| ^~~~~~~~~~~~~~~~~
Reviewed by: dim
Differential Revision: https://reviews.freebsd.org/D54869
(cherry picked from commit 72a6991b80c6e6c47a3b84337f62f0a02bd30391)
lib/virtual_oss: don't (over)link to libsamplerate
These plugins require samplerate.h due to virtual_oss's int.h including
it, but don't use any symbols directly so don't link to the library.
Centralize adding the include path.
Reviewed by: christos
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D54705
(cherry picked from commit d78291b0e9736f39f22c55c163978c1b92e601e4)
(cherry picked from commit c88f012faa13c39f13efdcef88d3141253a300ab)
virtual_oss: build system tidying
general:
- find libsamplerate's headers in the temporary sysroot instead of
digging in the source tree.
- use LIBADD where possible
lib/virtual_oss:
- centralize SHLIBDIR define
- centralize include path for internal headers
- don't try to find libsamplerate directly in .OBJDIR
No functional changes.
Reviewed by: christos
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D54704
(cherry picked from commit 373c72ad5044d5f84b7f3fa169d37e7214729f74)
epair: add VLAN_HWTAGGING
Add capability VLAN_HWTAGGING to the epair interface and enable it by
default.
When sending a packet over a VLAN interface that uses an epair
interface, the flag M_VLANTAG and the ether_vtag (which contains the
VLAN ID and/or PCP) are set in the mbuf to inform the hardware that
the VLAN header has to be added. The sending epair end does not need
to actually add a VLAN header. It can just pass the mbuf with this
setting to the other epair end, which receives the packet. The
receiving epair end can just pass the mbuf with this setting to the
upper layer. Due to this setting, the upper layer believes that there
was a VLAN header that has been removed by the interface.
If the packet later leaves the host, the outgoing physical interface
can add the VLAN header in hardware if it supports VLAN_HWTAGGING.
If not, the implementation of Ethernet or bridge adds the VLAN header
in software.
Reviewed by: zlei, tuexen
[2 lines not shown]
dpaa2: add support for several interface counters
Add support for IFCOUNTER_IPACKETS, IFCOUNTER_OPACKETS,
IFCOUNTER_OBYTES, IFCOUNTER_OMCASTS, IFCOUNTER_OERRORS, and
IFCOUNTER_OQDROPS.
This allows tools like systat to report the incoming and outgoing
bandwidth.
Reviewed by: dsl, Timo Völker
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54893
powerpc: explicitly cast the timebase printfs
This is causing compilation issues on powerpc:powerpc GENERIC.
(cherry picked from commit 03e4cc9fdeb2a6445f13cd41b471927a0f722fff)
powerpc: explicitly cast the timebase printfs
This is causing compilation issues on powerpc:powerpc GENERIC.
(cherry picked from commit 03e4cc9fdeb2a6445f13cd41b471927a0f722fff)
powerpc: add a best-effort SMP time base sync for G5's that need it
There's no timebase freeze platform routine registered on my dual 2.3GHz
G5 PPC970FX Apple PowerMac.
For platforms without an explicit timebase freeze/unfreeze, we'll have to
make do with what we have - which for now is an explicit hand-crafted
spinlock/rendezvous method.
* For existing platforms, they'll still continue to clock freeze /
rendezvous; albeit with some stronger atomic bits now (from jhibbits@.)
* Instead of the fallback being "no timesync", implement a
best-effort one which does a similar rendezvous barrier between
BSP and APs, but instead of freeze/unfreeze the first instruction
after the CPUs all register they're ready is to set the timebase.
This has resulted in many reboots of my Powermac G5 dual-socket device
correctly starting and running in SMP mode.
[4 lines not shown]
powerpc: fix release image building for Apple partitions
awk changed somewhere between 14 and 15 and it stopped accepting
a hexadecimal number as its input - it will always return 0.
This results in a very badly written apple boot block.
So just remove it; do the math in shell.
PR: kern/292341
Differential Revision: https://reviews.freebsd.org/D54639
Reviewed by: imp
MFC after: 1 week
(cherry picked from commit 7afa03963c448a14b1735a10eaf84941b0b74862)
powerpc: put the isync inside the TD_LOCK() checking loop
Fix a narrow window where the lock is unlocked but the checking CPU
hasn't flushed things appropriately.
Inside this window the CPU inside cpu_switch() will loop forever thinking
the destination thread is still blocked/locked even though it is not.
This manifests as the system hanging after starting all APs.
I've seen this reliably trigger in qemu-system-ppc64 running power9 pseries
guests; the more CPUs the more likely it triggers at boot.
PR: kern/292167
Differential Revision: https://reviews.freebsd.org/D54478
Reviewed by: jhibbits
MFC after: 1 week
Relnotes: yes
(cherry picked from commit 8df2e542146801fd01675e56724eaa567d04c209)
powerpc: add a best-effort SMP time base sync for G5's that need it
There's no timebase freeze platform routine registered on my dual 2.3GHz
G5 PPC970FX Apple PowerMac.
For platforms without an explicit timebase freeze/unfreeze, we'll have to
make do with what we have - which for now is an explicit hand-crafted
spinlock/rendezvous method.
* For existing platforms, they'll still continue to clock freeze /
rendezvous; albeit with some stronger atomic bits now (from jhibbits@.)
* Instead of the fallback being "no timesync", implement a
best-effort one which does a similar rendezvous barrier between
BSP and APs, but instead of freeze/unfreeze the first instruction
after the CPUs all register they're ready is to set the timebase.
This has resulted in many reboots of my Powermac G5 dual-socket device
correctly starting and running in SMP mode.
[4 lines not shown]
nanobsd: embedded: Stub out experimental functions
Stub out both experimental functions introduced in ecc039be7fdd when
doing embedded builds.
Fixes: ecc039be7fdd ("nanobsd: Add a NO_ROOT build option")
MFC after: 3 days
libc: Don't use uninitialised string for getnetbyaddr[_r](0) DNS lookup
If net is all-zero, the loop to extract all leading non-zero octets will
iterate zero times and leave nn with the value 4, which the following
switch statement to initialise qbuf does not handle. As a result,
_dns_getnetbyaddr will look up the PTR record for this uninitialised
string, which will leak the pre-existing contents of that stack memory
to the DNS resolver and, if remote and not otherwise protected, network.
Note that _dns_getnetbyaddr is only used if nsswitch.conf is configured
to enable the "dns" source for the "networks" database, which is not the
default configuration in FreeBSD.
For glibc this same bug, in code also derived from BIND's, was issued
CVE-2026-0915. This commit adopts the same behaviour as glibc's fix,
which is to regard a net of 0 as being for 0.0.0.0. Apparently NetBSD
will return NS_UNAVAIL instead, which may or may not make more sense,
but in general glibc compatibility tends to cause less friction when
there's not a good reason to avoid it.
[7 lines not shown]
