This is a display of mostly-automatically-classified git commits from 2026-01-26 to 2026-02-01.
Table of contents and commits per category:
| (0) | Highlighted commits (these are copies, not in stats) | |
| 0 | 0.0% | Userland programs |
| 9 | 5.3% | Documentation |
| 37 | 21.9% | Hardware support |
| 15 | 8.9% | Networking |
| 14 | 8.3% | System administration |
| 8 | 4.7% | Libraries |
| 0 | 0.0% | Filesystems |
| 37 | 21.9% | Kernel |
| 16 | 9.5% | Build system |
| 3 | 1.8% | Internal organizational stuff |
| 10 | 5.9% | Testing |
| 7 | 4.1% | Style, typos, and comments |
| 11 | 6.5% | Contrib code |
| 2 | 1.2% | Reverted commits |
| 0 | 0.0% | Unclassified commits |
| 169 | 100% | total |
| Technical notes about this page |
For extra visibility, these are copies of commits found in
other sections. Most (if not all) come from the commit message
containing "Relnotes:", or commits modifying
UPDATING.
-- no commits in this category this week --
Commits about commands found in man section 1 (other than networking).
-- no commits in this category this week --
Man pages, release notes, etc.
Fixes: https://cgit.freebsd.org/src/commit/?id=9bf69c37f43e96292e97e41bf942d7aca4101362 Sponsored by: The FreeBSD Foundation MFC after: 1 week
pf's divert-to action can be used to pass packets to a divert socket, but divert.4 didn't mention this, only referencing ipfw. Try to make the text a bit more general. Reviewed by: igoro, kp, glebius MFC after: 2 weeks Sponsored by: OPNsense Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D54848
Adopt the POSIX standard text to our implementation. PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206284 Reviewed by: des, jilles, ziaee Differential Revision: https://reviews.freebsd.org/D49895
Reviewed by: emaste, olce, ziaee Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54951
PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292820 Submitted by: Kraytonian MFC after: 1 week
+ Mention relevance of this file in the vt manual screen.font entry + The vidfont manual is in section one, not eight + Remove leftover blank line from freebsd tag removal MFC after: 3 days
Now that we have angle bracket characters for all common display sizes, sprinkle in the correct macros for the structures in this page. While here, fix a mdoc typo, a linter warning, and switch a parenthetical to a much smoother appositive. MFC after: 3 days Fixes: https://cgit.freebsd.org/src/commit/?id=7cd6da268a8f (vt.4: Style pass)
Hardware drivers and architecture-specific code.
Revert the argument change that broke libcam in 8c35de49 and move power_condition support to scsi_start_stop_pc(). Reported by: imp Reviewed By: #cam, imp (mentor) Sponsored by: Samsung Electronics Differential Revision: https://reviews.freebsd.org/D54822
Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D54875
acpi_spmc: Add system power management controller driver Add SPMC (system power management controller) driver as acpi_spmc. This is the device which provides the LPI device D-state constraints and allows for OSPM to send S0ix/modern standby entry/exit notifications. This supports the original Intel DSM (https://uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf, untested), the AMD DSM (tested), and the Microsoft DSM (tested). Before entry, acpi_spmc_check_constraints is called to notify of any violated power constraints. This will use acpi_pwr_get_state to get current device D-states when that gets added back. Reviewed by: olce Tested by: jkim, Oleksandr Kryvulia, Matthias Lanter Approved by: olce Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D48387
acpi: Add ACPI_SPMC debug layer define Reported by: des Fixes: https://cgit.freebsd.org/src/commit/?id=c5daa5a4c32c ("acpi_spmc: Add system power management controller driver") Sponsored by: The FreeBSD Foundation
acpi_spmc(4): Fix compilation on 32-bit platforms Fixes: https://cgit.freebsd.org/src/commit/?id=c5daa5a4c32c ("acpi_spmc: Add system power management controller driver") Sponsored by: The FreeBSD Foundation
Extend pmap_bootstrap_dmap() to build the DMAP with 4K-page granularity.
Recently we have been approximating it with 2MB mappings. The motivation
again is the problematic FU540 hardware, which seems to require more
accurate mappings still to avoid triggering its PMP errata.
Although this hardware alone is of little consequence, constructing the
DMAP accurately/correctly may help avoid future surprises.
The implementation contains some repetitive code. This could be
expressed differently, but my guiding principle for these early routines
is that being simple and explicit about what we are doing makes them
easier to comprehend.
See also 762a3224cde6 ("riscv: smarter DMAP construction).
Tested by: Klaus Küchemann <maciphone2@googlemail.com>
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D54716
sym(4): Consistently use device_printf(9) where applicable
sym(4): Use memcpy(9) instead of bcopy(9) The overlap handling of bcopy(9) is not required in these cases. Obtained from: BSD-licensed Linux sym53c8xx driver
sym(4): Provide a DEVICE_DETACH(9) method This also fixes sym_cam_free() to tear things down correctly, i. e. in opposite order of setup, as well as sym_cam_attach() to not free devq and SIM twice in the failure case.
sym(4): Employ memory barriers also on x86 In an MP world, it doesn't hold that x86 requires no memory barriers. This change should also fix panics due to out-of-sync data seen with FreeBSD VMs on top of OpenStack and HBAs of type lsiLogic. [1] While at it: - Improve the granularity somewhat by distinguishing between read and write memory barriers as well as refer to existing *mb(9) functions instead of duplicating these [2], unless IO barriers are also used. - Nuke the unused SYM_DRIVER_NAME macro. PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270816 [https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=1] Obtained from: BSD-licensed Linux sym53c8xx driver [2] MFC after: 1 week
Add an inline function hfence_gvma() for hfence.gvma instruction. Signed-off-by: Doongar Singh <doonbsd@gmail.com> Reviewed by: mhorne, markj Differential Revision: https://reviews.freebsd.org/D54857
This function handles invalid intermediate PTP entries, but there's no reason for this: the passed range should be mapped. In particular, we assert that all L3 entries encountered are mapped. So let's simplify the code a bit. No functional change intended. Reviewed by: andrew MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D54738
When the link is down don't set flags other than IFM_AVALID & IFM_ETHER This avoids `media: Ethernet autoselect (Unknown <full-duplex>)` on ifconfig Reviewed by: zlei, pouria Approved by: glebius (mentor) MFC after: 1 week Sponsored by: Stormshield Differential Revision: https://reviews.freebsd.org/D54573
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. Differential Revision: https://reviews.freebsd.org/D54821 Reviewed by: jhibbits
According to POWER8_UM_v1.3_16MAR2016 3.8.3 Translation Lookaside Buffer (TLB), POWER8 supports lockless TLBIE operations. Locally Tested: * IBM POWER8 Revision 2.0, dual socket, 160 threads Differential Revision: https://reviews.freebsd.org/D54855 Approved by: jhibbits
The driver should look for active queues and one potential default-queue in both halves of the split instead of stopping at the first valid default-queue. Fixes: https://cgit.freebsd.org/src/commit/?id=a9f476580eb0 cxgbe(4): fixes for netmap operation with only some queues active MFC after: 1 week Sponsored by: Chelsio Communications
Added RoCE support for BCM576xx controllers with below changes, 1. Update the BAR offsets for handling BCM576xx controllers. Use the values populated by the L2 driver for getting the Doorbell offsets. 2. Use msn index instead of tail to pull psn table entry. 3. Temporarily disable dbr pacing feature untill it is fully implemented. 4. Add support for 400G speed. Reviewed by: ssaxena Differential Revision: https://reviews.freebsd.org/D54521 MFC after: 3 days
Check FW flags for status of Resource Limits. If bit FUNC_QCAPS_RESP_FLAGS_EXT2_SW_MAX_RESOURCE_LIMITS_SUPPORTED is set, that means FW set the resource limit for L2 and RoCE. We'll then do the following: L2 driver would allocate context memory based on what FW reported. RoCE driver uses FW reported values without capping. These values are the total FW reported value minus L2 and other components shares. For example: FW reported max_qps = 137217 in L2 query, this includes: 5120 for L2 1025 for QP1 131072 for RoCE L2 will allocate backing store memory for the total. In RoCE query, we'll get max_qp = 131072 and use it without further capping. Reviewed by: ssaxena Differential Revision: https://reviews.freebsd.org/D54522 MFC after: 3 days
Currently driver is not considering the active_lanes while displaying the speed & width of port and hence it showing invalid active_speed and active_width values in the ibv_devinfo command output when two ports are aggregated at hardware level. Fixed the driver to consider the active_lanes while determining the active_speed & active_width values. Reviewed by: ssaxena Differential Revision: https://reviews.freebsd.org/D54523 MFC after: 3 days
Added support to display board_id in ibv_devinfo output. ibv_devinfo util reads the board_id from below sysctl attribute, so added this sysctl attribute. sys.class.infiniband.bnxt_reX.board_id Reviewed by: ssaxena Differential Revision: https://reviews.freebsd.org/D54524 MFC after: 3 days
Variable size WQE means that each send Work Queue Entry to HW can use different WQE sizes as opposed to the static WQE size on the current devices. Set variable WQE mode for BCM576xx devices. Depth of the Queue will be a multiple of slot which is 16 bytes. The number of slots should be a multiple of 256 as per the HW requirement. Initialize the Software shadow queue to hold requests equal to the number of slots. Reviewed by: ssaxena Differential Revision: https://reviews.freebsd.org/D54525 MFC after: 3 days
This function is not used outside of machdep.c and is already static on arm64 and riscv. Reviewed by: imp Effort: CHERI upstreaming Sponsored by: AFRL, DARPA Differential Revision: https://reviews.freebsd.org/D54838
Commit cc81c44dd806737f98b4fd4094674dd71c8749f3 aimed to consolidate duplicated code between the Book-E and AIM backends. For cpu_thread_alloc cpu_thread_alloc and cpu_fork it used the AIM functions which used a bogus alignment mask (~0x2f). The Book-E functions used a proper alignment mask (~0x3f). The AIM functions appear to have been busted since they were first imported in commit 919cb3362fded33aca682a6ac57777f8fff86e36. To fix, use the Book-E mask which requests 64 byte alignment. Probably this was harmless in practice since td_kstack is page aligned and struct pcb is probably a multiple of 32 bytes in size, so the 0x10 bit should have been clear anyway. Reviewed by: fuz, jhibbits Fixes: https://cgit.freebsd.org/src/commit/?id=cc81c44dd806 ("Unify ABI-related bits of the Book-E and AIM...") Effort: CHERI upstreaming Sponsored by: AFRL, DARPA Differential Revision: https://reviews.freebsd.org/D54839
Reviewed by: kib, jhibbits Effort: CHERI upstreaming Sponsored by: AFRL, DARPA Differential Revision: https://reviews.freebsd.org/D54840
Fixes: https://cgit.freebsd.org/src/commit/?id=cd036e891a35 ("ahc_pci.c: If bus_dma...") MFC after: 3 days Sponsored by: The FreeBSD Foundation
Previously, we would first call AcpiEvaluateObject() to execute \_Sx before calling AcpiGetSleepTypeData(). This was unnecessary, as AcpiGetSleepTypeData() performs the same call itself. While doing so, the latter function logs any other error than AE_NOT_FOUND (which indicates that a particular sleep state is not supported), which most probably is an added benefit of this change. Reviewed by: obiwac MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D54624
This has been possible since ACPICA 20240827, and is actually a requirement to get out of S3 on ACPI_REDUCED_HARDWARE (that said, we don't implement S3 on arm64 yet). Relevant ACPICA commit: https://github.com/acpica/acpica/commit/79cd933e7b370e8d3fb490bf36ca5d111a12f96a. Reviewed by: obiwac MFC after: 2 weeks MFC to: stable/15 Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D54625
Summary: Doing so will let the upper layer know how to deal with software hash, with benefits like inp_flowid can be set and m_pkthdr.flowid can be set in output path. Reviewed by: tuexen Differential Revision: https://reviews.freebsd.org/D54929
in kernel. Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
Reviewed by: olce Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
It is nop for 4BSD. Reviewed by: olce Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
For !SCHED_ULE, even if the fence is not needed, it is harmless. Reviewed by: olce Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
This is causing compilation issues on powerpc:powerpc GENERIC.
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
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: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292195
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D54532
This patch fixes three issues:
(1) Initially, set the hwassist flags correctly when enabling
transmit checksum offload for TCP/IPv6 and UDP/IPv6.
(2) Keep the hwassist flags in sync with the capabilities when
changing txcsum.
(3) Keep the hwasssit flags in sync with the capabilities when
changing txcsum6.
Without this patch, transmit checksum offloading for TCP/IPv6 and
UDP/IPv6 is never used and transmit checksum offloading for IPv4,
TCP/IPv4 and UDP/IPv4 is always used, even if disabled via
ifconfig ue? -txcsum.
Reviewed by: Timo Völker
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D54974
In the ice_if_promisc_set function, the driver currently disables the IFF_ALLMULTI flag, thereby preventing the activation of multicast mode. To address this issue, implement appropriate handling to ensure the flag is managed correctly. Signed-off-by: Yogesh Bhosale <yogesh.bhosale@intel.com> Tested by: Gowthamkumar K S <gowtham.kumar.ks@intel.com> MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D54186
Network-related commands, library, and kernel.
If a rule has a divert port set, then we can reasonably predict that ipdivert.ko is loaded, and in particular that ip_divert_ptr is set. Moreover, in this case, if ipdivert.ko is not loaded we should just drop the packet instead of ignoring the divert rule. Reviewed by: igoro, kp, glebius MFC after: 2 weeks Sponsored by: OPNsense Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D54845
The lock is sleepable and we can't grab it in dyn_tick(). Use the individual bucket locks instead. Fixes: https://cgit.freebsd.org/src/commit/?id=e3caa360d5d0a73af0de1d293d5b8ff6e900ceb4
The Jumbo Payload option was intended to allow the deployment of IPv6 on networks with a link MTU in excess of 65,735 octets. Speaking to one of the authors of RFC2675 the networks which motivated the Jumbo Payload option no longer exist. FreeBSD does not currently support any links with this capacity and discussion when this change was first proposed suggested that the loop back interface had to be patched to test implementation. As there are no known devices that can carry Jumbo Payloads remove support. Reviewed by: glebius, teuxen, kp Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D19960
There is no particular limitation of divert sockets with respect to IPv6, and the pf.conf man page does not mention the restriction to IPv4. Extend the divert-to regression tests to exercise the v6 case. Reviewed by: igoro, kp, glebius MFC after: 3 weeks Sponsored by: OPNsense Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D54847
No functional change intended. MFC after: 1 week Sponsored by: Stormshield Sponsored by: Klara, Inc.
The multicast routing code was using spin mutexes for packet counting, but there is no reason to use them instead of regular mutexes, given that none of this code runs in an interrupt context. Convert to using default mutexes. Reviewed by: glebius MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D54603
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
netinet6: Disallow connections to IN6ADDR_ANY Previously connect() or sendto() to INADDR_ANY or IN6ADDR_ANY reached some socket bound to some host interface address. Although this was intentional it was an artifact of a different era, and is not desirable now. In 417b35a97b76 markj added support to disallow connect() to INADDR_ANY and IN6ADDR_ANY. Connections to INADDR_ANY were disabled by default in cd240957d7ba. Follow suit with IN6ADDR_ANY. Reviewed by: glebius, markj, zlei Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D54306
tests/netinet: fix tests that depended on connect(in6addr_any) Fixes: https://cgit.freebsd.org/src/commit/?id=627e126dbb07b167b028380ef61bb45f10493938
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 MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D52465
No functional change intended. MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc.
No functional change intended. MFC after: 1 week Sponsored by: Stormshield Sponsored by: Klara, Inc.
PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254611 Approved by: otis, tuexen, des MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D54375
Stuff in man section 8 (other than networking).
pci_host_read_config() requires write access to /dev/pci so cannot be used with unprivileged bhyve. The lpc init code uses it to find the host system's LPC bridge device and so was generating warnings with bhyve running as a non-root user. Refactor the implementation to use PCIOCGETCONF instead, which doesn't require any special privileges. This isn't formally necessary, as we only care about copying the host system's identifiers in order to support Intel GPU passthrough (see commit f4ceaff56ddaa), but it's straightforward and lets an unprivileged user run bhyve without seeing warnings about failing to open /dev/pci with write permissions. Reviewed by: corvink, rew MFC after: 3 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D54851
Sponsored by: NVidia networking MFC after: 1 week
Need to check argument 'path', not just allocated struct member.
PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292595 Approved by: ziaee, dab, imp, tsoome MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D54843
lposix is the last holdout of modules built into flua until we can fix the module design to have the right parts require()able. Address a valid bug in lua_read() found at a higher WARNS and drop the override entirely. Some of the modules could possibly be re-evaluated. Fixes: https://cgit.freebsd.org/src/commit/?id=c2caf3b3313 ("flua: lposix: add more useful functions [...]") Reported by: des Reviewed by: des Sponsored by: Klara, Inc. Sponsored by: NetApp, Inc.
Previously, setting an interface FIB to some invalid value would result in a warning being printed, but the ifconfig command would exit with status 0, but this is wrong. Add a little regression test. Reviewed by: pouria, zlei, melifaro MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D54918
Avoid truncating 32-bit values. This would have saved me a bit of time when I was looking at a cpuid leaf on my system and typed 0x80000001f instead of 0x8000001f. Reviewed by: kib MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D54919
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@gmail.com MFC after: 1 week
PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292595 Reviewed by: imp MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D54923
On some environement a VM can be connected to multiple ifaces but only one will respond to dhcp and able to fetch the metadata. Launch the early dhclient on all available ifaces and as soon as one dhcp has successfully configured an iface, proceed with fetching the metadata. MFC After: 1 week Reported by: mateusz.klejn@ovhcloud.com Tested by: mateusz.klejn@ovhcloud.com Sponsored by: OVHcloud
Stub out both experimental functions introduced in ecc039be7fdd when doing embedded builds. Fixes: https://cgit.freebsd.org/src/commit/?id=ecc039be7fdd ("nanobsd: Add a NO_ROOT build option") MFC after: 3 days
This fixes the build with GCC 14 on stable/14 which raises fatal -Wimplicit-function-declaration warnings. Reviewed by: rmacklem, cy Fixes: https://cgit.freebsd.org/src/commit/?id=5000d023a446 ("heimdal-kadmin: Add support for the -f dump option") Differential Revision: https://reviews.freebsd.org/D54931
This fixes a warning reported by GCC 14 on stable/14:
crypto/heimdal/lib/hdb/keys.c:241:13: warning: 'free' called on pointer 'ext' with nonzero offset 16 [-Wfree-nonheap-object]
241 | free(hist_keys);
| ^~~~~~~~~~~~~~~
crypto/heimdal/lib/hdb/keys.c:234:15: note: returned from 'calloc'
234 | ext = calloc(1, sizeof (*ext));
| ^~~~~~~~~~~~~~~~~~~~~~~~
Reviewed by: rmacklem, cy
Fixes: https://cgit.freebsd.org/src/commit/?id=5000d023a446 ("heimdal-kadmin: Add support for the -f dump option")
Differential Revision: https://reviews.freebsd.org/D54932
Compare to the OUTPUT_ARCH in sys/conf/ldscript.riscv. Reviewed by: mhorne Differential Revision: https://reviews.freebsd.org/D54962
Reviewed by: asomers Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54879
Reviewed by: asomers Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54879
Sponsored by: Klara, Inc.
This change fixes two NULL pointer dereferences caused by the __bt_first function. The first was caused by returning 0 (i.e., RET_SUCCESS) when a key was not found, causing the caller to dereference an uninitalized or NULL pointer. The second one was caused by an if statment clobbering a local variable with a function call result that might be NULL. Reported by: clang-tidy Sponsored by: Klara, Inc. Reviewed by: markj Obtained from: https://github.com/apple-oss-distributions/libc (partially) Differential Revision: https://reviews.freebsd.org/D54905
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. Reviewed by: markj (secteam) Fixes: https://cgit.freebsd.org/src/commit/?id=1363f04ce1b8 ("get* rework and new bind code") MFC after: 1 day Security: Same bug as glibc's CVE-2026-0915
Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54898
Do not allocate or switch to the custom stack on non-x86. Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54898
If no resolver configuration was found, we would fall back to INADDR_ANY and IN6ADDR_ANY. This made sense when it was first written thirty or forty years ago but not today, especially since connecting to INADDR_ANY or IN6ADDR_ANY is no longer supported. Switch to the loopback address and simplify the code. Note that (as the pre-existing comment in the code states) running without a resolver configuration is not really supported. Still, if we're going to have a hardcoded fallback, it might as well work. PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291790 MFC after: 1 week Reviewed by: kevans Differential Revision: https://reviews.freebsd.org/D55011
-- no commits in this category this week --
Kernel stuff (other than networking, filesystems, and drivers).
Allow MODULE_DEPEND to accept macros by adding an extra level of indirection. Some drivers in the tree actually depend on this being the case. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D54874
devstat: Provide 32-bit compatibility If a 32-bit process running on a 64-bit kernel requests kern.devstat.all, translate each struct devstat to its 32-bit equivalent before copying it out. Also fix a bug where an early error would be ignored if there were no devices to report. MFC after: 1 week Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D54591
freebsd32: Fix includes The previous commit added <sys/cdefs.h>, which isn't actually needed. Conversely, <sys/event.h> is needed (and has been for a long time) but was not included. MFC after: 1 week Fixes: https://cgit.freebsd.org/src/commit/?id=a11d132f6c62 ("devstat: Provide 32-bit compatibility") Reported by: gallatin@
When witness(4) detects lock order reversals (LORs), it prints information about the stack trace which caused the LOR. If available, it can also print information about the first stack trace which established the other lock ordering. However, it only does this for "simple" LORs where the two locks in question were directly locked in the opposite order. When the lock order was established through a more complex pattern of intermediate locks, WITNESS only prints the stack trace where it detected the LOR. This commit provides new functionality to provide more verbose information about the lock chain(s) which established the lock ordering. The new functionality can be disabled by setting the debug.witness.trace sysctl/tunable to 1. The new functionality is also available through the debug.witness.badstacks sysctl, which has been modified to always show the more verbose information. Reviewed by: markj, glebius (previous version), kib (previous version) Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D54785 MFC after: 1 month
Mark the lock relationships defined in order_lists[] and use that information to print better messages when a LOR violates one of these relationships. Suggested by: markj Reviewed by: kib, markj MFC after: 1 month Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D54903
The tag is used to perform lookup in a different way. New functions were introduced: * to set, check and clear a tag * to walk through a radix tree based on a given tag Furthermore, the `radix_tree_delete()` function was modified to clear tags on deletion. The amdgpu DRM driver started to use this in Linux 6.10. While here, the `radix_tree_gang_lookup()` function was added because it is very close to `radix_tree_gang_lookup_tag()`, but it is not used by the DRM drivers as of this commit. Reviewed by: emaste Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D54503
Printing an empty netdev_features= line makes little sense even under bootverbose. Sponsored by: The FreeBSD Foundation MFC after: 3 days
Reviewed by: olce Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
There is no harm in having unused prototypes. Reviewed by: olce Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
It is not used since c72188d85a793c7610208beafb83af544de6e3b7. Noted by: jrtc27 Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
Reviewed by: olce Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
This is the infrastructure to allow scheduler implementation to be selected on boot, supported by ifuncs. The DEFINE_SHIM() macros and their usage provided by jrtc27@. Reviewed by: olce Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
Reviewed by: olce Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
Reviewed by: olce Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
sys: Make sched_ule a sched instance Reviewed by: olce Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
sys: Move ULE sysctls under kern.sched.ule Reviewed by: olce Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
sys: Make sched_4bsd a sched instance Reviewed by: olce Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
sys: Move 4BSD sysctls under kern.sched.4bsd Reviewed by: olce Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
Reports all compiled-in schedulers. Reviewed by: olce Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
Move the code to decide on the timer accounting into the scheduler hook. Since there were no inclusion of opt_sched.h, it is probably done unconditionally anyway. Reviewed by: olce Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
Add sched_find_l2_neighbor(). This really should be not scheduler-depended, in does not have anything to do with scheduler at all. But for now keep the same code structure. Reviewed by: olce Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
Reviewed by: olce Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
It is apparently should be considered part of the ABI, and is used by the base top(1). But do not declare the ccpu variable in headers, it is needed only by 4bsd. So put the variable definition into sched_shim.c to make the kernel buildable without SCHED_4BSD. Reviewed by: olce Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
Globally enable both schedulers for LINT. Enable both schedulers for GENERIC on amd64. Reviewed by: olce Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
kern/sched: move duplicate preemption stat vars into sched_shim.c Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
kern/sched: deduplicate sdt probes Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
kern/sched: deduplicate dtrace hook vars Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
I have hit the case multiple times that some LinuxKPI field may not be set during driver bringup and lindebugfs would cause a panic. The backtrace goes like: strlen() at strlen+0x54 pfs_create_dir() at pfs_create_dir+0x41 debugfs_create_dir() at debugfs_create_dir+0xa1 ... While the problem is clearly in LinuxKPI or the driver, we likely should at least add an assert to pfs_create_dir() if name is NULL like we have for pfs_add_node() but for lindebugfs at least make this a graceful error and continue without creating the dir instead of panicing. Sponsored by: The FreeBSD Foundation MFC after: 3 days Reviewed by: kevans Differential Revision: https://reviews.freebsd.org/D54944
maybe_resched() needs to schedule TDA_SCHED for curthread, but this requires taking curthread lock while owning some other thread lock. To avoid introducing the order: - Use a scheduler-private TDP flag. - Register an unconditional TDA_SCHED_PRIV for 4BSD. When an AST needs to be scheduled, i.e. the current thread must do context switch in the return to userspace path, set the flag. Then the ast handler calls ast_scheduler(), which gives the same effect as scheduling TDA_AST. The overhead is a single function call on each userspace return, for 4BSD case. Reported and tested by: pho (previous version) Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54945
The try_binary_file() function has inverted logic for the FIRMWARE_GET_NOWARN flag. When the flag is set (meaning "don't warn"), the code sets warn=true and makes noise anyway. Invert the assignment to warn to correctly suppress warnings when FIRMWARE_GET_NOWARN is set. Reviewed by: kevans Differential Revision: https://reviews.freebsd.org/D54955
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 too serious. Reported and tested by: pho Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54831
clang is more tolerant and implies this extension whereas GCC is stricter and requires it to be included. Reviewed by: mhorne Differential Revision: https://reviews.freebsd.org/D54965
These are needed when compiling a RISC-V kernel with GCC which does not inline __builtin_ffs*. The __ffsdi2 is adapated from the previous ffsl.c. This partially reverts commit f4db342d44198973c1c7b9005d0c5683a582707e. Reviewed by: mhorne Differential Revision: https://reviews.freebsd.org/D54967
These are only needed for GCC, but it doesn't hurt to include these always. Reviewed by: mhorne Differential Revision: https://reviews.freebsd.org/D54968
When calling sctp_peeloff() on a SOCK_SEQPACKET socket, the created and returned socket has the type SOCK_STREAM. This is specified in section 9.2 of RFC 6458. Reported by: Xin Long MFC after: 3 days
Add kernel ifunc support on arm. MFC after : 3 weeks Reviewed by: kib (previous version) Differential Revision: https://reviews.freebsd.org/D54970
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: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286710, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291409 Tested by: marck, rdunkle@smallcatbrain.com Reviewed by: emaste MFC after: 3 days Fixes: https://cgit.freebsd.org/src/commit/?id=2e47f35be5dc ("Convert libllvm, libclang and liblldb into private shared libraries"). Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D54815
To facilitate comparison with mtree -C generated output, keep the keywords ordered. No functional change intended. Reviewed by: imp MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D54872
Reviewed by: asomers Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D54899
Build fails with BHYVE_SNAPSHOT enabled on non-amd64, so add it to BROKEN_OPTIONS for these arches. PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292686 Reviewed by: emaste, markj MFC after: 3 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D54873
These warnings were already marked with -Wno-error=, but they trigger so many false positives in libc++ headers to be utterly useless for C++ code, so disable them entirely for C++. Reviewed by: imp, dim Differential Revision: https://reviews.freebsd.org/D54867
GCC 15 does not like a push_back() invocation in utils::find_core()
and incorrectly believes libc++ will free a non-heap pointer. Disable
the warning to pacify GCC.
In function 'void std::__1::__libcpp_operator_delete(_Args ...) [with _Args = {void*, long unsigned int}]',
inlined from 'void std::__1::__do_deallocate_handle_size(void*, size_t, _Args ...) [with _Args = {}]' at /usr/obj/.../amd64.amd64/tmp/usr/include/c++/v1/new:298:39,
inlined from 'void std::__1::__libcpp_deallocate(void*, size_t, size_t)' at /usr/obj/.../amd64.amd64/tmp/usr/include/c++/v1/new:311:39,
inlined from 'void std::__1::allocator<_Tp>::deallocate(_Tp*, size_t) [with _Tp = utils::fs::path]' at /usr/obj/.../amd64.amd64/tmp/usr/include/c++/v1/__memory/allocator.h:132:31,
inlined from 'static void std::__1::allocator_traits<_Alloc>::deallocate(allocator_type&, pointer, size_type) [with _Alloc = std::__1::allocator<utils::fs::path>]' at /usr/obj/.../amd64.amd64/tmp/usr/include/c++/v1/__memory/allocator_traits.h:314:19,
inlined from 'std::__1::__split_buffer<_Tp, _Allocator>::~__split_buffer() [with _Tp = utils::fs::path; _Allocator = std::__1::allocator<utils::fs::path>&]' at /usr/obj/.../amd64.amd64/tmp/usr/include/c++/v1/__split_buffer:365:31,
inlined from 'std::__1::vector<_Tp, _Alloc>::pointer std::__1::vector<_Tp, _Alloc>::__push_back_slow_path(_Up&&) [with _Up = utils::fs::path; _Tp = utils::fs::path; _Allocator = std::__1::allocator<utils::fs::path>]' at /usr/obj/.../amd64.amd64/tmp/usr/include/c++/v1/vector:1504:1,
inlined from 'void std::__1::vector<_Tp, _Alloc>::push_back(value_type&&) [with _Tp = utils::fs::path; _Allocator = std::__1::allocator<utils::fs::path>]' at /usr/obj/.../amd64.amd64/tmp/usr/include/c++/v1/vector:1526:34,
inlined from 'utils::optional<utils::fs::path> utils::find_core(const fs::path&, const process::status&, const fs::path&)' at contrib/kyua/utils/stacktrace.cpp:217:25:
/usr/obj/.../amd64.amd64/tmp/usr/include/c++/v1/new:274:38: error: 'void operator delete(void*, size_t)' called on pointer '<unknown>' with nonzero offset [24, 9223372036854775807] [-Werror=free-nonheap-object]
274 | __builtin_operator_delete(__args...);
| ^
In function 'void* std::__1::__libcpp_operator_new(_Args ...) [with _Args = {long unsigned int}]',
inlined from 'void* std::__1::__libcpp_allocate(size_t, size_t)' at /usr/obj/.../amd64.amd64/tmp/usr/include/c++/v1/new:289:31,
inlined from '_Tp* std::__1::allocator<_Tp>::allocate(size_t) [with _Tp = utils::fs::path]' at /usr/obj/.../amd64.amd64/tmp/usr/include/c++/v1/__memory/allocator.h:118:54,
inlined from 'constexpr std::__1::__allocation_result<typename std::__1::allocator_traits<_Alloc>::pointer> std::__1::__allocate_at_least(_Alloc&, size_t) [with _Alloc = allocator<utils::fs::path>]' at /usr/obj/.../amd64.amd64/tmp/usr/include/c++/v1/__memory/allocate_at_least.h:41:27,
inlined from 'std::__1::__split_buffer<_Tp, _Allocator>::__split_buffer(size_type, size_type, __alloc_rr&) [with _Tp = utils::fs::path; _Allocator = std::__1::allocator<utils::fs::path>&]' at /usr/obj/.../amd64.amd64/tmp/usr/include/c++/v1/__split_buffer:353:49,
inlined from 'std::__1::vector<_Tp, _Alloc>::pointer std::__1::vector<_Tp, _Alloc>::__push_back_slow_path(_Up&&) [with _Up = utils::fs::path; _Tp = utils::fs::path; _Allocator = std::__1::allocator<utils::fs::path>]' at /usr/obj/.../amd64.amd64/tmp/usr/include/c++/v1/vector:1498:47,
inlined from 'void std::__1::vector<_Tp, _Alloc>::push_back(value_type&&) [with _Tp = utils::fs::path; _Allocator = std::__1::allocator<utils::fs::path>]' at /usr/obj/.../amd64.amd64/tmp/usr/include/c++/v1/vector:1526:34,
inlined from 'utils::optional<utils::fs::path> utils::find_core(const fs::path&, const process::status&, const fs::path&)' at contrib/kyua/utils/stacktrace.cpp:216:25:
/usr/obj/.../amd64.amd64/tmp/usr/include/c++/v1/new:265:42: note: returned from 'void* operator new(size_t)'
265 | return __builtin_operator_new(__args...);
| ^
Reviewed by: imp, dim
Differential Revision: https://reviews.freebsd.org/D54868
Instructions in /etc/pkg/FreeBSD.conf and elsewhere recommend putting changes in /usr/local/etc/pkg/repos/FreeBSD.conf so bring OCI containers into line as well. Reviewed by: dfr, ivy Differential Revision: https://reviews.freebsd.org/D54090 MFC after: 5 days Sponsored by: SkunkWerks, GmbH
We always use NO_ROOT for release artifact builds, so remove the alternate code paths. For the first step we set NO_ROOT unconditionally in cases that invoke submakes, and turn NO_ROOT being unset into an error in lover-level targets so that we can catch potential out-of-tree build scripts (or missed in-tree cases) that expect to run not-NO_ROOT builds. The second step will be to remove those entirely. Reviewed by: cperciva Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D54179
Reviewed by: emaste, ziaee Differential Revision: https://reviews.freebsd.org/D54688
Fixes: https://cgit.freebsd.org/src/commit/?id=f74f891581bc ("src.opts: Introduce MK_SOUND") PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291853 Sponsored by: The FreeBSD Foundation MFC after: 4 days
Fixes: https://cgit.freebsd.org/src/commit/?id=d78291b0e973 ("lib/virtual_oss: don't (over)link to libsamplerate") Reported by: pkg-fallout Sponsored by: The FreeBSD Foundation MFC after: 2 days
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
Skip this test if mqueuefs isn't loaded. Unfortunately, that will skip the entire googletest test program, including test cases that don't require mqueuefs. But the test's own skipping logic doesn't work, and we don't yet have a googletest-compatible require_kmods() function. MFC after: 2 weeks Sponsored by: ConnectWise Reviewed by: emaste, ngie Differential Revision: https://reviews.freebsd.org/D54902
No functional change, but downstream in CheriBSD this was causing a link error as the Makefile was overriding CFLAGS set via a side effect of bsd.compiler.mk. Reviewed by: bz, brooks, emaste Sponsored by: AFRL, DARPA Differential Revision: https://reviews.freebsd.org/D54894
Reviewed by: mhorne Differential Revision: https://reviews.freebsd.org/D54963
This change cleans up example tests for atf, googletest, plain, and TAP when MK_EXAMPLES=no. Not having this in results `kyua test -k /usr/tests/share/examples/Kyuafile` being broken on a host where the content in that directory tree is stale. I ran into that case because at some point in time in the past I had specified `MK_GOOGLETEST=no` one of my dev instances. MFC after: 1 week
MFC With: 09984871d8caff9263b955a94bb9fb5354af1b4c Sponsored by: ConnectWise
MFC With: 5c2ee618d5ec21f110c4da40e9f17833b2ab8b76 Sponsored by: ConnectWise
MFC With: 4d707825bf62ee73a32b615846eff9c4a9bda538 Sponsored by: ConnectWise
Tests should declare their dependencies rather than testing for them at runtime. Reviewed by: igoro, kp, glebius MFC after: 2 weeks Sponsored by: OPNsense Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D54846
First problem is a trivial race that the client thread doesn't see updated c.sbytes. Second problem applies only to the truncate test. On a machine with huge default buffer sizes, there is a chance that sendfile(2) will fill both buffers with amount of data that is larger than the size we plan to truncate. To minimise chances for this scenario, increase file size and truncate it less aggressively, also try to decrease buffer sizes.
Google developed the Capsicum unit test suite[1] as part of the Capsicum-Linux[2] project, based on unit tests that existed in FreeBSD and unit tests developed as part of the initial Capsicum-Linux port. Capsicum-Linux was archived as of October 31, 2022 and is no longer being maintained. FreeBSD is currently the only consumer of and contributor to the test suite. Move the src into tests/sys/capsicum to simplify ongoing maintenance. The makefiles were deleted as we (continue to) use the existing bespoke FreeBSD Makefile, and CONTRIBUTING.md was removed as the Google CLA is no longer applicable. [1] https://github.com/google/capsicum-test [2] https://github.com/google/capsicum-linux Reviewed by: asomers, oshogbo Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D54917
touch: Tests for -h flag Reviewed by: kevans Approved by: kevans Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D54836
touch: Test for -a flag Reviewed by: kevans Approved by: kevans Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D54852
touch: Test for -m flag Reviewed by: kevans Approved by: kevans Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D54853
No functional change intended. MFC after: 1 week Sponsored by: Stormshield Sponsored by: Klara, Inc.
These could go in other categories, but it's more clear if they're here instead.
No functional change intended. MFC after: 1 week Sponsored by: Stormshield Sponsored by: Klara, Inc.
Some out of order chars.
No functional change. Sponsored by: The FreeBSD Foundation MFC after: 3 days
Also fix some bogus libxo format strings in mroute6.c, and close a couple of lists instead of opening them twice. Fixes: https://cgit.freebsd.org/src/commit/?id=ade9ccfe211a ("Convert netstat to use libxo.") MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc.
Many standard C++ headers do not have the .h file extension: some, such as `iostream`, lack it; others have a .hpp file extension. Moreover, some projects (like ATF/Kyua) also contain .ipp files, which are C++ "interface" files. Relax the regular expression to ensure that non-traditional C "system" headers, C++ headers, etc, with angle brackets are sorted before "local" headers. MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D54401
- s/arithmatic/arithmetic/ MFC after: 5 days
- s/transcation/transaction/ MFC after: 5 days
It's necessary for auditd to be able to log its events. Note that the recently added pdwait() syscall is only auditable because an audit event of that name was preemptively added back in 2012. PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292739 MFC after: 1 week Fixes: https://cgit.freebsd.org/src/commit/?id=5c2ee618d5e "sys: add pdrfork(2)" Sponsored by: ConnectWise Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D54897
[libc++] Work around new GCC 15 type_traits builtins that can't be
used as Clang's can (#137871)
GCC 15 has added builtins for various C++ type traits that Clang
already had. Since `__has_builtin(...)` now finds these, the #if
branches previously only used for Clang are now used for GCC 15.
However, GCC 15 requires that these builtins only be used in type
aliases, not in template aliases.
For now, just don't use the `__has_builtin(...)` branches under newer
GCC versions, so both 14 and 15 work during the transition. This
can be cleaned up later to use all the GCC 15 builtins available.
Fixed: #137704
Fixed: #117319
Reviewed by: dim
Differential Revision: https://reviews.freebsd.org/D54865
Fixes the following warning from GCC 15:
contrib/netbsd-tests/lib/libc/regex/t_regex_att.c:54:30: error: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (4 chars into 3 available) [-Werror=unterminated-string-initialization]
54 | static const char delim[3] = "\\\\\0";
| ^~~~~~~~
Reviewed by: ngie, imp, dim
Differential Revision: https://reviews.freebsd.org/D54866
This is a rollup commit from upstream to fix: Improper validation of PBMAC1 parameters in PKCS#12 MAC verification (CVE-2025-11187) Stack buffer overflow in CMS AuthEnvelopedData parsing (CVE-2025-15467) NULL dereference in SSL_CIPHER_find() function on unknown cipher ID (CVE-2025-15468) "openssl dgst" one-shot codepath silently truncates inputs >16MB (CVE-2025-15469) TLS 1.3 CompressedCertificate excessive memory allocation (CVE-2025-66199) Heap out-of-bounds write in BIO_f_linebuffer on short writes (CVE-2025-68160) Unauthenticated/unencrypted trailing bytes with low-level OCB function calls (CVE-2025-69418) Out of bounds write in PKCS12_get_friendlyname() UTF-8 conversion (CVE-2025-69419) Missing ASN1_TYPE validation in TS_RESP_verify_response() function (CVE-2025-69420) NULL Pointer Dereference in PKCS12_item_decrypt_d2i_ex function (CVE-2025-69421) Missing ASN1_TYPE validation in PKCS#12 parsing (CVE-2026-22795) ASN1_TYPE Type Confusion in the PKCS7_digest_from_attributes() function (CVE-2026-22796) See https://openssl-library.org/news/secadv/ for additional details. Approved by: so Obtained from: OpenSSL Security: FreeBSD-SA-26:01.openssl Security: CVE-2025-11187 Security: CVE-2025-15467 Security: CVE-2025-15468 Security: CVE-2025-15469 Security: CVE-2025-66199 Security: CVE-2025-68160 Security: CVE-2025-69418 Security: CVE-2025-69419 Security: CVE-2025-69420 Security: CVE-2025-69421 Security: CVE-2026-22795 Security: CVE-2026-22796
The test sometimes crashes with ASLR enabled. This seems to happen when regcomp() grows the process stack and happens to run into the virtual memory limit set at the beginning of the test. ASLR triggers the problem since it introduces a bit of fragmentation and thus introduces cases where stack allocation can be the trigger of virtual memory exhaustion, rather than dynamic memory allocation in regcomp(). Make the test stable by priming the stack before doing anything else. This effectively reserves 16MB of virtual memory for the stack, which in practice is enough to make the test stable on amd64. PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259971 Reviewed by: ngie, emaste MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D54880
The changes between the two versions can be found in this diff of the two release tags: https://github.com/google/googletest/compare/v1.15.2...v1.17.0 One notable change is that GoogleTest 1.17.0 now requires C++-17 to build. MFC after: 1 week Merge commit '3a4c29b5bed4ea20266ad9371fbfdc6bca088f92'
Clang's -Wmissing-variable-declarations flags this as an issue since the flag is only used in `gtest.cc`. Declare the flag beforehand to ensure that the variable scope is properly limited to `gtest.cc`. MFC after: 1 week MFC with: 46333229c6a0187ebf231805682ee0bceed704d1 Ref: https://github.com/google/googletest/pull/4898
This change adds OpenSSL 3.5.5 from upstream [1]. The 3.5.5 artifact was been verified via PGP key [2] and by SHA256 checksum [3]. This is a security release, but also contains several bugfixes. All of the CVE-worthy issues have already been addressed on the target branch(es), so the net-result is that this is a bugfix release. More information about the release (from a high level) can be found in the release notes [4]. MFC after: 1 week 1. https://github.com/openssl/openssl/releases/download/openssl-3.5.5/openssl-3.5.5.tar.gz 2. https://github.com/openssl/openssl/releases/download/openssl-3.5.5/openssl-3.5.5.tar.gz.asc 3. https://github.com/openssl/openssl/releases/download/openssl-3.5.5/openssl-3.5.5.tar.gz.sha256 4. https://github.com/openssl/openssl/blob/openssl-3.5.5/NEWS.md Merge commit '808413da28df9fb93e1f304e6016b15e660f54c8'
OpenSSL: update vendor sources to match 3.5.5 content MFC with: f25b8c9fb4f58cf61adb47d7570abe7caa6d385d MFC after: 1 week
OpenSSL: commit sys/crypto changes for 3.5.5 These files were changed as part of the 3.5.4 -> 3.5.5 upgrade. Please see the upstream release notes linked in 1731fc70f7344af08db49b06c63c963fa12ee354, et al, for more details. MFC after: 6 days MFC with: 1731fc70f7344af08db49b06c63c963fa12ee354 Fixes: https://cgit.freebsd.org/src/commit/?id=1731fc70f7344af08d ("OpenSSL: update vendor sources to match 3.5.5 content")
This release adds several new characters critical to the manual pages that were previously missing on high-dpi displays: em-dash, en-dash, hyphen, angle brackets, white square, dagger, and double dagger. It also features improved alignment for numerous characters in different sizes. Thanks: Fredric Cambus MFC after: 3 days Discussed with: emaste
src.opts.mk: Enable LLDB by default globally Previously it was enabled for all architectures except but RISC-V. Upstream made significant progress on RISC-V support over the last year[1], and although there's still some FreeBSD-specific work to do we can start building it now. [1] https://jonasdevlieghere.com/post/lldb-2025/ Sponsored by: The FreeBSD Foundation
Revert "src.opts.mk: Enable LLDB by default globally" This breaks the riscv64 build; clearly the version we have in-tree is not new enough to work. That or our build system needs tweaking. Either way, we're not ready for this, and enabling it without testing was misguided. This reverts commit c59a47dc6c016dff74466cecb160459980a5d782.
Not classified automatically, and waiting for manual attention.
-- no commits in this category this week --
Dates:
cgit.freebsd.org/src. Git accurately records the
order of commits, but not their dates.Automatic grouping:
This reverts commit \\b([0-9a-fA-F]{40})\\b
and the hash was found in this week's commits.
Automatic categories:
Source code:
Generated with commits-periodical 0.20 at 2026-02-09 19:12:17+00:00.
This work is supported by Tarsnap Backup Inc.
Alternate version: 2026-01-26 (debug) (contains info about the classification)