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
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]
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
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]
hwpmc: add regression tests for counting-PMC counter wraparound
Exercise a process-mode counting PMC whose accumulated count crosses,
or already exceeds, the range of the underlying hardware counter.
Before the previous commit, the first context switch after the
hardware counter wrapped panicked INVARIANTS kernels with "negative
increment" and silently corrupted the accumulated count on other
kernels.
The tests need a hardware counting event backed by a counter narrower
than 64 bits 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/D58341
(cherry picked from commit 2cfd82f747c04f68f679824ba627460e87ab3848)
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: 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: 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 counting-PMC counter wraparound
Exercise a process-mode counting PMC whose accumulated count crosses,
or already exceeds, the range of the underlying hardware counter.
Before the previous commit, the first context switch after the
hardware counter wrapped panicked INVARIANTS kernels with "negative
increment" and silently corrupted the accumulated count on other
kernels.
The tests need a hardware counting event backed by a counter narrower
than 64 bits 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/D58341
(cherry picked from commit 2cfd82f747c04f68f679824ba627460e87ab3848)
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]
ifconfig: Improve CMIS parsing of breakout configs
This fixes a bug where we do not report all lanes when
a NIC configures a breakout. Eg, we reported all 4
lanes when a NIC configured the optics as 1x400g, but
only printed the first lane's strength when configured as
4x100g.
Fix this by actually parsing the active lane count, rather
than pulling it from the default descriptor.
While here, optionally print page 10h when -vvvv is
specified. This aids in determining how a breakout is configured.
I put it under an extra level of verbosity, as I don't want
to let things get out of hand printing CMIS pages.
Sponsored by: Netflix
Reviewed by: kib, sumit.saxena_broadcom.com
Differential Revision: https://reviews.freebsd.org/D58263
pf: attempt to handle overlapping group and interface names
pf assumes that network groups and network interfaces share a namespace
(that is, a name is unused, a group or an interface, never both a the
same time). Unfortunately this assumption was broken when interface
renaming was introduced.
Attempt to cope with this rather than panicking. Note that this is a
band-aid, not a full solution. The correct fix is for the network stack
to go back to enforcing a single namespace for groups and interfaces.
PR: 297220
Reported by: Robert Morris
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
pf: fix securelevel off-by-one
cmd_securelevel is the securelevel at which the call should be denied.
pf (write) calls should be denied at level 3 or up (not at 2 or up as it
was), so increment these all by one.
PR: 296838
MFC after: 4 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D58377
netinet6: Fix some issues with passing v4-mapped groups to IPv6 sockets.
1. EFAULT was happening because sooptcopyin() from inp_join_group() was
seeing the user-space thread descriptor in the faked-up sockopt. So, do
not attempt a user copyin(); defer to C99 initialization nulling sopt_td
for us to force a KVA memcpy().
2. It seems necessary to byte-swap ipv6mr_multiaddr.s6_addr32[3] on amd64
for similar reasons as to how the user-space initialization needed for
passing an IPv4-mapped group address also requires byte-swapping of the
0x0000FFFF field for s6_addr32[2]; it is a direct assignment to a integer
member of a struct, NOT a memcpy().
3. The assignment to imr_interface within in6_v6_mreq_to_v4() was obfuscated
by a cast back to its own type due to use of the IA_SIN() macro. Elided.
With this change, the feature gap seems to be closed; tested with a simple
link-scope IPv4 group under 224.0.0.0/24 with an mlx5(4) SR-IOV VF in bhyve.
[2 lines not shown]
mtest: Add support for exercising IPv4-mapped groups on IPv6 sockets.
This is in lieu of a full Kyua/ATF regression test, as this is an optional
feature that was beyond the scope of IETF's normative references for IPv6
multicast; support has been strictly on a best-effort basis.
Two new commands are added to mtest(8):
u mcast-addr ifname - join IPv4-mapped group on IPv6 socket
v mcast-addr ifname - leave IPv4-mapped group on IPv6 socket
Add an internal helper function __in6_v4_to_v4mapped() to perform the
converse of the IN6_IS_ADDR_V4MAPPED() check to support this use case.
Whilst __in6_v4_to_v4mapped() returns its first argument as a convenience,
avoid the temptation to dereference a pointer to that which we already hold.
Strictly the use of sockunion_t within mtest(8) more generally is a form
of controlled type punning (aliasing). Use a temporary as we overwrite
contents of su; the resultant write would overlap memory locations.
[2 lines not shown]
ppp: Avoid overflow when formatting endpoint discriminator options
Each byte of the address is represented by a pair of characters, so we
should be multiplying len by 2 when figuring out how much buffer space
we have. Previously, a sufficiently large option could cause an
overflow of the global "result" buffer.
Reported by: Joshua Rogers <joshua at joshua.hu>
Tested by: Décio Brandão (0xDBJ)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58555
libelftc: Const correctness for C23
On some platforms, e.g. Linux Clang 22.1.8 / glibc 2.43, strchr()
now implements the C23 behaviour where passing a const pointer to
strchr() also returns a const pointer. This breaks libelftc during
the bootstrap build, since it assumes the return value is always
a mutable pointer.
Since the returned pointer is never modified in either case, make
it const.
MFC after: 1 week
Reviewed by: jkoshy, markj, dim, emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58497
mandoc: Const correctness for C23
On some platforms, e.g. Linux Clang 22.1.8 / glibc 2.43, strchr()
now implements the C23 behaviour where passing a const pointer to
strchr() also returns a const pointer. This breaks mandoc during
the bootstrap build, since it assumes the return value is always
a mutable pointer.
In read.c, make the existing temporary pointer const, and for the
mandoc_asprintf() call, add a new mutable local.
In mdoc.c and out.c, since the data is mutable and is mutated here,
remove const from the temporary pointers.
MFC after: 1 week
Reviewed by: fuz
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58495
m4: Const correctness for C23
On some platforms, e.g. Linux Clang 22.1.8 / glibc 2.43, strchr()
now implements the C23 behaviour where passing a const pointer to
strchr() also returns a const pointer. This breaks m4 during the
bootstrap build, since it assumes the return value is always a
mutable pointer.
Since the returned value is never modified, simply make the
temporary const.
MFC after: 1 week
Reviewed by: bapt, dim
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58494
mkimg: Const correctness for C23
On some platforms, e.g. Linux Clang 22.1.8 / glibc 2.43, strchr()
now implements the C23 behaviour where passing a const pointer to
strchr() also returns a const pointer. This breaks mkimg during
the bootstrap build, since it assumes the return value is always
a mutable pointer.
Make the existing 'sep' pointer const to fix the first case, and
for the second, introduce a new non-const pointer for strchr,
since we do modify the result in that case.
MFC after: 1 week
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58493
