Drop -Winline from CDIAGFLAGS it breaks on sparc64
On sparc64 ssh/unittests/kex fails to build with:
usr.bin/ssh/libcrux_mlkem768_sha3.h:8196: warning: inlining failed
in call to 'libcrux_ml_kem_polynomial_ZERO_89_ea':
--param max-inline-insns-single limit reached
OK djm@ (long time ago) reminded by tb@
Fix orc riscv64-specific code paths
orc previously failed to build because of inconsistent #ifdefs that
exposed Linux-only calls. While here hook up call to
(__builtin)__clear_cache and correct default assumptions (the 'V'
extension can't be assumed, on any OS).
Prompted by a report from matthieu@, maintainer timeout, ok sthen@
add missing build dep. it wouldn't build without the build dep being
available, so no need for a REVISION bump.
noticed by myself and naddy on arm64 and amd64 bulk package builds.
OK sthen@
x86: rename and clean up __copy_from_user_inatomic_nocache()
From Linus Torvalds
03fd014cd9f3a3d173740ab9c5cbede82fd6322c in linux-6.18.y/6.18.24
5de7bcaadf160c1716b20a263cf8f5b06f658959 in mainline linux
drm/amdkfd: Fix queue preemption/eviction failures by aligning control stack size to GPU page size
From Donet Tom
647fb0dc3818733024fc96c1df1ec3af806b0256 in linux-6.18.y/6.18.24
78746a474e92fc7aaed12219bec7c78ae1bd6156 in mainline linux
Fix difftime() result when it is passed a negative value
We need to cast the result of bitwise AND to time_t before the cast
to double in the HI and LO macros. Otherwise, we get a very large
positive floating point value instead of a negative value.
Reported by Xuntao Chi
drm/amdgpu: Handle GPU page faults correctly on non-4K page systems
From Donet Tom
6a9f2683c66dc54d3598589684c0b3c5cb2862ad in linux-6.18.y/6.18.24
4e9597f22a3cb8600c72fc266eaac57981d834c8 in mainline linux
pf_purge_states() may trip assert(st->timeout == PFTM_UNLINKED)
in pf_free_state(). Once member ->timeout in pf_state structure
reaches PFTM_UNLINKED value, then the ->timeout member must not
not be updated. This diff reminds pfsync(4) to follow PFTM_UNLINKED
rule too. The pfsync(4) currently may accidentally update ->timeout
member while state is being purged, causing pf_purge_states() to
trip the assert.
Issue was kindly reported by Stuart Henderson.
OK @bluhm
fix tx dma segment size
i thought it was weird that an MI driver like ix(4) is using an MD
number like PAGE_SIZE for the maximum segment size in its tx dma
maps. the manual says tx segments can be 16k (and goes into a 16bit
field), so let's try using the documented value here.
the rx descs also use 16 * 1024 as a magic number here, so it's in
keeping with other code in the same driver.
tested by me on arm64 and sparc64 (which has 8k pages)
tested by and ok jan@
SECURITY update to openvpn-2.6.20
fix race condition in TLS handshake that could lead to leaking of packet
data from a previous handshake under specific circumstances
(CVE-2026-40215)
fix server ASSERT() on receiving a suitably malformed packet with
a valid tls-crypt-v2 key (CVE-2026-35058)
Other changes: https://github.com/OpenVPN/openvpn/blob/v2.6.20/Changes.rst
fix rss hashing on big endian archs
i noticed that packets seem to be hashed differently by the network
stack and this hardware on sparc64. mucking around with how we
handle the endianness of the rss key programmed via registers makes
it consistent on both big and little archs.
tested by me on sparc64 and arm64
ok claudio@
increase the 9k mbuf clusters to 9k + 128 bytes
pools try to amortise the cost of items against the underlying
kernel memory allocator by rounding the "page" size up to fit at
least 8 items, and then rounding that up to the next power of 2.
the 9k clusters are 9 * 1024 bytes, which is 72k after being
multiplied by 8, which becomes 128k cos it's the next power of 2.
if you divide 128k by 9k, you get 14 and some change. there's enough
change that we can raise the cluster size by 128 bytes without
affecting the page size or the number of items on the page. ie,
it's still going to use 128k "pages" and fit 14 clusters.
i can take advantage of this in some drivers for stupid hardware,
so given the above it seems like a plan without any drawbacks apart
from the pool name getting a bit bigger.
ok claudio@
sys/cnmac: support CN71xx 1000BASE-X ports
Some CN71xx boards describe active GMX ports only in the PIP device
tree, and mark the CPU facing link as cavium,sgmii-mac-1000x-mode with
cavium,disable-autonegotiation, but without a PHY handle. OpenBSD
otherwise trusts GMX0_INF_MODE for port discovery and insists on a PHY
attach in cn30xxgmx_attach(), so such ports never reach cnmac with a
usable media setup.
Enumerate CN71xx SGMII ports from pip/interface at N when that description
is present, carry the 1000x and disable-autonegotiation flags into the
per port state, and let cnmac seed fixed 1000baseT full duplex media for
that case. Ports that still use a normal SGMII PHY path continue to go
through cn30xxsmi_get_phy() and mii_attach() unchanged.
Tested on two CN71xx Octeon systems: Juniper SRX300, which uses
1000BASE-X DT ports, and Ubiquiti EdgeRouter 4, which does not.
OK: visa@
When updating the ranges after an insertion or deletion, the range
should be up to and including the current line number.
This behavior is consistent with historic vi as well as modern vim.
Reported by Tim Case, fix from Walter Alejandro Iglesias
grow the buffer to hold the sprintf'd rtable id by 8 bytes so it can hold
the full range an int can express.
the previous buffer was large enough since the rtable id is clamped to 0..
RT_TABLEID_MAX which is 255, however, it is a bit much to ask for analyzers -
including those in compilers - to detect that, 8 extra bytes on the stack
cost us effectively nothing, and it feels a bit more robust.
triggered by bcook's portable diffs, ok claudio
