FreeBSD git weekly: 2026-10-05 to 2026-10-11

trap() and set_mcontext() change the FP/VMX/VSX ownership state in
several steps with preemption enabled.  A context switch in between
leaves the thread computing with another thread's register contents:

- enable_fpu()/enable_vec() set PCB_FPU/PCB_VEC before loading the
  registers, so a switch mid-load saves a half-loaded unit over the PCB.
- set_mcontext() clears the frame's MSR bits and then the PCB flags;
  a switch in between re-enables the unit, and the thread returns to
  user space with it enabled but not owned, so it is neither saved nor
  restored until the next signal.

Both paths run after every sigreturn(2), setcontext(2) and
swapcontext(3).  A POWER9 test that keeps f14-f31 live across a signal,
with other threads using the FPU on the same CPU, saw 283 corrupted
round trips out of 882000; none after this change.

Hold a critical section around both, as amd64 and arm64 do.

Reviewed by:    jhibbits
MFC after:      1 week
Differential Revision:  https://reviews.freebsd.org/D60054

dev.igc.N.fc read and wrote a function-static variable shared by every
igc device, so a read returned the last value written to any of them (3
until the first write), not the state of the device.  The softc value
started as 0, which is also the value of "no flow control", while the
hardware was set up for full flow control.  As a result:

- Writing 0 was taken for no change and did nothing, unless another
  value had been written to that device before.
- igc_reset() took a softc value of 0 for "not set", so a device set to
  0 went back to full flow control on the next init.
- With more than one receive queue the driver enabled per-queue drop
  (SRRCTL.DROP_EN), which is meant for a MAC that does not send pause
  frames, although the MAC was told to send them.
- Values out of range were accepted and ignored.

A write only forced the MAC's flow control bits.  The pause bits
advertised to the link partner, the pause thresholds and DROP_EN stayed
as the last init had set them, and the next link event resolved flow
control from the stale advertisement again: a port set to 0 came back
honoring pause frames, for example.

Start the softc value as full, report it, use it as it is in
igc_reset(), reject invalid values, and apply a change by
reinitializing the interface, as the dmac and eee_control sysctls do.

Two things behave differently now.  Changing the mode of a running
interface takes the link down to renegotiate.  And with the default
mode and more than one receive queue DROP_EN is no longer set: a full
receive ring makes the MAC send pause frames, and holds up the other
queues, where it used to drop that queue's packets.  Setting fc to 0 or
1 selects per-queue drop.

Tested on I226-V ports with four receive queues: for each mode, the
flow control bits in CTRL, the pause thresholds and DROP_EN were read
back, and the mode the link partner resolved, also after a down/up.

Reviewed by:            gallatin
Fixes:                  https://cgit.freebsd.org/src/commit/?id=517904de5cca ("igc(4): Introduce new driver for the Intel I225 Ethernet controller.")
MFC after:              2 weeks
Sponsored by:           Rubicon Communications, LLC ("Netgate")
Differential Revision:  https://reviews.freebsd.org/D60363

The GICv5 ACPI code uses CpuInterfaceNumber to as the CPU ID. This a
GICv5 CPU ID and may not be the same as the appropriate FreeBSD value.

It is also possible the target CPU is disabled, e.g. when the hw.ncpu
tunable is uses to limit CPUs. If this is the case we don't want to
enable the CPU in the cpu set as it is offline so cannot handle
interrupts.

Switch to use ArmMpidr to find which pcpu to use when finding which
CPUs the IRS is attached to.

Fixes:  https://cgit.freebsd.org/src/commit/?id=9556306213e1 ("arm64: Add ACPI support to GICv5 driver")
Differential Revision:  https://reviews.freebsd.org/D59993
Sponsored by:   Arm Ltd

Avoid allocating per-transfer maps for coherent tags that cannot
bounce. Retain maps for cache synchronization, CCA realms, and KMSAN.
These un-used maps carry with them memory and cache miss overheads.

Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D60098
Sponsored by: Netflix

MFC after:      3 days
Sponsored by:   The FreeBSD Foundation

MFC after:      3 days
Sponsored by:   The FreeBSD Foundation

We cannot simply treat a pointer to struct oin6_aliasreq as a pointer to
struct in6_aliasreq: the latter is larger.  In particular, the store to
ifra->ifra_vhid is out of bounds.

Since OSIOCAIFADDR_IN6 does not need to copy data back out, it can
simply use a struct in6_ifaliasreq on the stack.

Reported by:    Andrew <xxx.sys@protonmail.com>
Reviewed by:    pouria
MFC after:      1 week
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D60184

The TCP-over-UDP ICMP callback receives ip6c_m as a borrowed chain owned
by icmp6_notify_error.  It used m_pulldown() to obtain a contiguous UDP
header even though that API frees the complete chain when the requested
range is unavailable.  The callback could then return without
propagating the lost ownership, leaving raw ICMP delivery to read and
free a stale head.

Validate that the complete UDP header was quoted, copy it through the
chain with m_copydata(), and temporarily advance the parser offset
instead of consuming bytes from the caller-owned packet.

A remote sender can reach the old path when TCP UDP tunneling is enabled
by quoting the configured local UDP source port in an ICMPv6 error and
including only four through seven UDP-header bytes.

Signed-off-by: Andrew Griffiths <andrew@calif.io>

Reviewed by:    pouria, tuexen, markj
MFC after:      1 week
Differential Revision:  https://reviews.freebsd.org/D60143

For a lightly used ring iflib_txd_db_check() may defer zero descriptors,
so its "pending >= limit" test is true even when nothing has been queued
since the last doorbell.  iflib_txq_drain() calls it before, inside and
after its loop, so a sender that drains its own packet wrote the tail
register three times per packet, twice with the value the hardware
already had.

The log of 81be655266fa ("iflib: ensure that tx interrupts enabled and
cleanups") calls skipping the doorbell when db_pending is zero "an
obvious missing optimization"; the comparison against a limit of zero
defeated it.  vmx(4) and mgb(4) have dropped such repeated requests in
the driver since 2019.  Return early when nothing is pending.

Reviewed by:            gallatin
MFC after:              2 weeks
Sponsored by:           Rubicon Communications, LLC ("Netgate")
Differential Revision:  https://reviews.freebsd.org/D60290

PR:           https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=299059

Reviewed by:  wulf
Differential Revision:  https://reviews.freebsd.org/D60275

PR:           https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=299013
Reported by:    Trond.Endrestol@ximalas.info
Reviewed by:    emaste
Fixes:          https://cgit.freebsd.org/src/commit/?id=222210c6a822 ("libgcc_s: add libgcc_s_asneeded.so wrapper for gcc 16")
MFC after:      3 days
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D60252

MFC after:      3 days
Sponsored by:   The FreeBSD Foundation