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
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
[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
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.
[4 lines not shown]
[mlir][OpenACC] Privatize worker reduction accumulators per worker (#210456)
Example:
```fortran
!$acc parallel
!$acc loop gang reduction(+:sum)
do k = 1, p
!$acc loop worker reduction(+:sum)
do j = 1, n
!$acc loop vector reduction(+:sum)
do i = 1, m
sum = sum + a(i,j,k)
end do
end do
end do
```
In this code, the worker accumulator is both gang- and worker-scoped.
Shared
[4 lines not shown]
RuntimeLibcalls: Migrate to dag libcall predicates
Switch to using dag predicates instead of free-form code predicates.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
[NFC][AMDGPU] Use SIInstrFlags predicates in SIMemoryLegalizer and AMDGPUBaseInfo. (#209821)
Part of a series following the introduction of SIInstrFlags predicates.
gurk: update to 0.10.0.
## [0.10.0] - 2026-07-19
This release significantly improves startup time and memory usage: messages
are no longer loaded into memory all at once at startup, but fetched in a
window around the current selection directly from the database. As a result,
the app starts fast regardless of the size of the message history.
### 🚀 Features
- Add XDG, env var, and CLI support for config/data paths (#523)
- Replace text with emoji while typing (#549)
- Support tab to autocomplete emoji (#558)
### 🐛 Bug Fixes
- Assure data dir exists (#547)
- Don't clear unread messages when navigating channels (#534)
[15 lines not shown]
[lldb][test] Double the timeout for TestGuiSpawnThreads.py (#210043)
If the host machine is overloaded, spawning threads may be delayed due
to lack of resources. I'm pretty sure this is the cause of failures in
GitHub CI reported in
https://github.com/llvm/llvm-project/issues/209874.
For what the test is doing, we unfortunately cannot get around needing
to wait on the test program.
We could perhaps come up with a lit mode that runs some tests in serial,
but this is a larger project than I want to get into now.
For now, let's try doubling the timeout. This test is unlikely to fail
for real, so if it's taking a long time, it'll be due to system
resources. In 99% of cases, it'll pass in a few seconds still.
rumdl: update to 0.2.37.
Added
reflow: add atomic_spans configuration and refactor inline wrapping (#742) (aeabec1)
Changed
BREAKING: the MD013 emphasis-spans option is renamed to atomic-spans (default true), with inverted meaning (emphasis-spans = true is now atomic-spans = false). Configs setting the old key should migrate; it is no longer recognized
Fixed
reflow: keep code spans atomic when wrapping would collapse whitespace (d43618b)
Stop a VM before destroying its backing zvols on delete
Deleting a VM with `zvols=true` tore down the backing zvols before stopping the domain, so ZFS could be pulled out from under a live qemu process — risking in-flight corruption and leaving zvols that fail to destroy with EBUSY. The `force` option also didn't really gate deleting a running VM despite what its description implied.
Reject deleting an active (running/suspended) VM unless `force` is set, and stop/undefine the domain before touching its zvols so the block devices are released first; the `force` field description now matches that behaviour. Picked up a few smaller VM-plugin tidy-ups along the way: clone rollback unwinds the snapshots/clones (and half-created VM record) it made if something fails partway, the disk-convert guard treats suspended VMs like running ones, and the convert path check looks at the real destination directory rather than its parent — with unit tests for the convert checks.
Revert "[GVN] Remove the "private" `llvm::gvn` namespace (NFC)" (#210666)
Reverts llvm/llvm-project#210323
FAILED: lib/Transforms/Scalar/CMakeFiles/LLVMScalarOpts.dir/GVN.cpp.o
/var/llvm-compile-time-tracker/llvm-project/llvm/lib/Transforms/Scalar/GVN.cpp:4001:27:
error: qualified name does not name a class before ‘:’ token
4001 | class llvm::GVNLegacyPass : public FunctionPass {
ports-mgmt/pkg: update to 2.8.0
Major Changes:
==============
Database & performance
- better read/write concurrency on the local DB
- Schema bumped to v42: 15 redundant single-column indexes dropped, flavors VIEW added, shlib_id indexes added
- Read-only databases opened with SQLITE_OPEN_READONLY, falling back to immutable=1
- Binary repositories: 16K pages and synchronous=OFF during bulk catalog updates
- Implicit SQL-89 JOINs converted to explicit JOIN syntax, several queries optimized
- Some database concurrency issues fixed
New features
- pkg-checksum(8): new command to generate and validate checksums
- Blake2b used everywhere possible for checksums; repositories use blake2 instead of sha256
- rwhich: file tracking and search for remote repositories (requires repositories to be built with -l)
- pkg delete -G/--exclude-glob: exclude packages by glob pattern
- Repositories: enable/disable/reset support
[51 lines not shown]
[libc++][NFC] Removed duplicated `_LIBCPP_INTRODUCED_IN_LLVM_23` macros (#210602)
Removed the redundant macros, which apparently were added by two
different patches.
Pull up following revision(s) (requested by riastradh in ticket #391):
libexec/ld.elf_so/rtld.c: revision 1.228
libexec/ld.elf_so/xmalloc.c: revision 1.27
ld.elf_so: Fix reversed sense of previous change to ASSERT macro.
Had tested the part of the change replacing botch("p") by botch(#p);
then didn't test the change from `if (!(p)) botch(#p)' to
`(__predict_false(p) ? botch(#p) : (void)0)'. Oops.
Now I have tested this with MALLOC_DEBUG enabled in ld.elf_so.
PR lib/59751: dlclose is not MT-safe depending on the libraries
unloaded
ld.elf_so: Set _rtld_objself.refcount = 1.
This is the object for ld.elf_so itself. It can be opened with
[17 lines not shown]
