ip_mroute: Don't assume that a multicast router is running
The SIOCGETSGCNT handler may be invoked in this scenario, and if no
router has initialized the lookup table, we'll have
mfct->mfchashtbl == NULL.
PR: 297148
Reported by: Robert Morris
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
sys/ofed: don't stop removing stale RoCE GIDs at the first hole
When cleaning up stale GIDs the scan stopped as soon as
rdma_get_gid_attr() failed. But that can also happen for empty entries
in the middle of the table, so a single gap left everything after it
behind and the GID entries could eventually run out.
Now the whole table is scanned and the empty slots are simply skipped.
Reviewed by: kib, jhb
Sponsored by: Nvidia networking
Fixes: 6a75471dbcf0 ("OFED: Various changes from Linux 4.19")
Differential revision: https://reviews.freebsd.org/D58510
sys/ofed: fix GID table reference leak in roce_gid_update_addr_callback()
The "add missing GIDs" loop uses rdma_find_gid_by_port() to test whether
a GID already exists, but forgets to drop the reference it returns. So
every rescan that finds an existing GID leaks one, which pins the entry
and prevents its slot from ever being freed on delete.
Just release the reference once the GID is found, like the "remove stale
GIDs" loop already does.
Reported by: Wafa Hamzah <wafah at nvidia.com>
Reviewed by: kib, jhb
Sponsored by: Nvidia networking
Fixes: 6a75471dbcf0 ("OFED: Various changes from Linux 4.19")
Differential revision: https://reviews.freebsd.org/D58511
x11-fonts/nerd-fonts: Update to 3.5.0
Upstream renamed the D2Coding font to D2Koding due to license reasons.
Consequently, the x11-fonts/nerd-fonts-d2coding subport has moved to
x11-fonts/nerd-fonts-d2koding accompanied by an entry in the MOVED file.
Added subports:
- x11-fonts/nerd-fonts-annotationmono
- x11-fonts/nerd-fonts-googlesanscode
Changed licenses:
- x11-fonts/nerd-fonts-agave (MIT -> OFL11)
- x11-fonts/nerd-fonts-arimo (APACHE20 -> OFL11)
- x11-fonts/nerd-fonts-cousine (APACHE20 -> OFL11)
Changelog:
https://github.com/ryanoasis/nerd-fonts/releases/tag/v3.5.0
PR: 297246
[2 lines not shown]
fts: refactor to use fd-relative operations internally
Replace all _open() calls with _openat() in __fts_open(), fts_read(),
and fts_children(). Replace statfs() with _fstatfs().
Add fts_dirfd to struct _ftsent, set to the file descriptor of the
parent directory. Callers can use openat(ent->fts_dirfd, ent->fts_name,
...) to access files safely without relying on fts_accpath, which
enables programs in capability mode to open the files described by
_ftsent.
This is a preparatory change for fts_openat() which will allow callers
to provide a pre-opened directory fd, enabling fts(3) traversal inside
Capsicum capability mode.
Mirror all fts_open() changes to fts_open_b().
As a result of expanding _ftsend, publish new ELF symbol versions for
fts_openat and related functions.
[4 lines not shown]
security/caldera: change RUN_DEP from net/haproxy24 to net/haproxy to unbreak index
- Checked code, it's referenced only by a config and will probably work
with every version of haproxy
devel/llvm23: welcome 23.1.0-rc2
Update to the first usable snapshot of the 23.1.0 release (RC1 lacked
distfiles). Connect to the build.
Sponsored by: DARPA, AFRL
devel/llvm23: bootstrap from devel/llvm22
This is an unmodified copy of llvm22 (except for the removal of the
just added patch files/patch-backport-93a67259cf23 which we won't need).
The next commit will convert this this to llvm23 and attach it to the
tree.
Sponsored by: DARPA, AFRL
kqueue: stream the knote report instead of buffering all of it
kern_proc_kqueues_out() sized its intermediate sbuf from the preceding
sizing pass, so dumping core for a process with many knotes wired a
buffer as large as the entire report.
Shrank the intermediate to one page and added a drain that copied into
the caller's sbuf up to maxlen, stopping the walk once it was reached.
Truncation stayed byte exact.
A dump of 384k knotes peaked at 20 KB of M_SBUF instead of 445 MB.
Reviewed by: adrian, markj
Differential Revision: https://reviews.freebsd.org/D58584
MFC after: 1 week
kqueue: fix the always-empty NT_PROCSTAT_KQUEUES core note
sbuf reserves a byte of its buffer for the terminator, so the sbuf
created with maxlen held one byte less than the sizing pass had
computed. The last record overflowed it, sbuf_bcat() failed, and the
error == 0 guard skipped the copy into the caller's sbuf, so the note
has been emitted at full size but zero filled since 5e7c43ff02dc.
Fixes: 5e7c43ff02dc
Reviewed by: adrian, markj
Differential Revision: https://reviews.freebsd.org/D58583
MFC after: 1 week
irc/unreal: Update 6.1.9.1 => 6.2.6
Port changes:
- Drops LIB_DEPENDS and configure flag for libmaxminddb as there
is a new built-in GeoIP database (mmdb).
- No longer RUN_DEPENDS on geoipupdate as the new database reloads
on start or rehash.
Changelog:
https://github.com/unrealircd/unrealircd/blob/unreal60_dev/doc/RELEASE-NOTES.md#unrealircd-626
PR: 297176
Reported by: Matthew Horan <matt at matthoran.com> (author)
Approved by: tanawts at gmail.com (maintainer)
Approved by: osa, vvd (Mentors, implicit)
MFH: 2026Q3
(cherry picked from commit 0e55a5b8c5945203b0fab7078a3ef1ae5674ed93)
irc/unreal: Update 6.1.9.1 => 6.2.6
Port changes:
- Drops LIB_DEPENDS and configure flag for libmaxminddb as there
is a new built-in GeoIP database (mmdb).
- No longer RUN_DEPENDS on geoipupdate as the new database reloads
on start or rehash.
Changelog:
https://github.com/unrealircd/unrealircd/blob/unreal60_dev/doc/RELEASE-NOTES.md#unrealircd-626
PR: 297176
Reported by: Matthew Horan <matt at matthoran.com> (author)
Approved by: tanawts at gmail.com (maintainer)
Approved by: osa, vvd (Mentors, implicit)
MFH: 2026Q3
tests/sys/pmc: only build if MK_PMC != no
This unbreaks the build when pmc support is explicitly disabled via the
aforementioned build knob.
MFC after: 10 days
Fixes: 2cfd82f74 ("hwpmc: add regression tests for ...")
Differential Revision: https://reviews.freebsd.org/D58401
(cherry picked from commit a18e773d2776a65c1a2a0418cbec9cf5ef526b53)
hwpmc: drain a process-mode PMC's runcount when a live target detaches
A process-mode PMC's runcount tracks how many CPUs currently have it
loaded in hardware. It is decremented only by the context-switch-out
and process-exit reclaim paths, both of which the scheduler invokes
only for processes flagged P_HWPMC. Detaching a target that still has
the PMC live in hardware dropped the target and cleared P_HWPMC without
taking the PMC off the hardware or dropping the runcount reference, so
the reference leaked. A subsequent release then spun in
pmc_wait_for_pmc_idle() forever waiting for the runcount to reach zero:
on an INVARIANTS kernel this panics ("waiting too long for pmc to be
free"), otherwise it is an unkillable loop holding the hwpmc lock. Any
process able to allocate a PMC can trigger this by attaching a counting
PMC to itself and detaching it before releasing.
Take the PMC off the hardware and drop the runcount reference as part
of detaching, before P_HWPMC is cleared: reclaim it from the detaching
thread's own CPU directly, and, when the detach removes the PMC's last
target, wait for any references held by the target's other threads to
[8 lines not shown]
hwpmc: add regression tests for detaching a live process-mode PMC
Attach a process-mode counting PMC to the current process, start it,
then detach and release it while it is still loaded on the hardware -
the case that previously leaked the PMC's runcount reference and
wedged pmc_wait_for_pmc_idle() at release. A second case does the same
from a multi-threaded process so the sibling threads' references have
to be drained too.
The tests need an allocatable process-mode counting event and skip
where none is available (hwpmc(4) not loaded, or a VM without a vPMU).
Reviewed by: adrian
MFC after: 2 weeks
Assisted-by: Claude Code (Fable 5)
Differential Revision: https://reviews.freebsd.org/D58343
(cherry picked from commit 3c3f886e4bc7619f7847ad0d0f996088ddf5915a)
hwpmc: handle counter wraparound for process-mode counting PMCs
The accumulated count of a process-mode counting PMC is kept in a
64-bit software counter and seeded into the hardware counter at every
context switch in. Hardware counters are narrower than that - each
PMC class discovers and records its own counter width, e.g. 48 bits
on current x86 (queried from CPUID on Intel, architectural on AMD) -
so once the accumulated count approaches the end of the hardware
counter range, the counter wraps during a time slice and the value
read back at switch out is smaller than the value seeded. The
increment was computed assuming a full 64-bit counter: on INVARIANTS
kernels a long enough counting run panics with "negative increment"
the moment the accumulated count first crosses the hardware counter
range, and on other kernels the totals silently lose a full counter
range per wrap.
Compute the increment modulo the per-class hardware counter width
instead, in both places that accumulate switch-out deltas.
[6 lines not shown]
