taskqueue: Move wakeup() out of tq_mutex
taskqueue KPI require wakeup() to be called for each completed
task. With everything else there heavily optimized over the years,
even when doing nothing this wakeup()'s lock/unlock is significant.
Since no external taskqueue consumer can depend on the tq_mutex,
we can move the wakeup() out of it. It creates some complications
for internal waiters, but those should be much more rare, and can
be handled with separate locked wakeups on demand.
My tests of taskqueue-intensive ZFS RAIDZ writes on 64-core system
show performance improvement from this change ~4%, while same time
reducing CPU usage by several percent due to lower lock contention,
confirmed by CPU profiler.
[lldb] Search for a corefile's images before loading any of them
A userland or kernel corefile can list hundreds of images, and searching for
one can shell out to a symbol server or fetch over the network. Searching for
them one at a time is where loading such a corefile spends its time.
Add a batch form of SymbolLocator::Locate that runs the searches on the
debugger's thread pool, gated on target.parallel-module-load. Results come
back in the order the requests were given, since that order decides the
Target's module order. Only the results are ordered, and anything a search
reports to the user arrives in whatever order the searches finish in.
Only the plugin searches run concurrently, so a platform hook does not have to
be thread safe to take part, and reading a binary's UUID out of memory stays
on the calling thread.
Setting up a platform binary can replace the Target's platform and dynamic
loader, and now happens for every image before any of them is searched for, so
the platform a corefile asks for is the one all of its images are searched
[4 lines not shown]
[lldb] Consult the platform before the symbol locator plugins (NFC)
A symbol locator plugin has no Platform to consult, so a platform that knows
where its binaries live cannot take part in a search. The only way to reach
one is Platform::GetSharedModule, which also creates the module and registers
it, so the lookup cannot be reused by a caller that wants to search for many
binaries before creating any.
Add a hook that only answers where the files are. An answer ends the search,
so an override owns what the plugins would otherwise have been asked for.
No platform overrides it yet. A follow-up moves PlatformDarwinKernel's kext
and kernel index lookups behind it.
Assisted-by: Claude
[lldb] Add a unified entry point for locating a binary and its symbols
The three-plugin composition that finds a binary and its symbol file is open
coded in several places. Give it one home, as a pure function of a module
spec, so that a caller holding several binaries can search for all of them
before creating any.
Nothing on this path takes a lock, where ModuleList::GetSharedModule holds the
shared module list's lock across the plugin search. That is what will make
searching for several binaries at once worth doing.
A miss that nothing could explain gets its own error type rather than an error
code, because a Status carrying an errno converts to the same llvm::ECError,
and a caller composing its own message for a plain miss must not swallow a
failure to reach a symbol server.
DynamicLoader's search no longer runs twice for a binary that is not already
known, and a module created from a located binary is now registered in the
shared module list, so a second Target asking for the same binary reuses it.
[2 lines not shown]
[RISC-V] Use an optional offset for C/Zc* extension instruction
Add uimm*_optional via OptionalMemOffsetAsmOperand and use it for the
instructions to allow dropping the "(${rs1})" zero-offset aliases.
This commit was prepared with the help of AI.
Reviewed By: topperc
Pull Request: https://github.com/llvm/llvm-project/pull/211674
Reconcile license derived config when the license changes
This commit adds changes to converge every subsystem whose configuration is derived from the license once that license changes. `truenas.license.upload` regenerated exactly one etc group and then fired `system.post_license_update` detached. That was survivable while gates asked `is_enterprise`, which expanded to `is_ha_capable OR (licence AND model AND not freenas)` -- on appliance hardware the first limb was already true before any license was installed, so those gates did not change their answer when one arrived and never re-rendering them cost nothing. Now that they are feature key checks they do change their answer, and a spread of etc groups were left silently stale until something unrelated regenerated them or the box rebooted. The plainest case is sudoers, where sudo command auditing simply did not turn on when an appliance was licensed.
Each affected subsystem now registers a LicenseReconcileDelegate from its own setup, naming the etc groups it owns and what should happen once they have been re-rendered, and a runner walks the eight of them on the hook. Doing this per plugin rather than centrally in etc matters because the right action genuinely differs between them: the block target delegates render without touching a live target and skip entirely when their service is stopped, the ones backing a running daemon reload it so that it picks the new config up, and ctdb gets a restart because the presence of its config file is what decides whether the daemon can start at all. Registration refuses a duplicate name or a group another delegate already claims, so two plugins cannot quietly both own one.
The hook is still fired detached, so the upload itself does not wait on the pass. What the runner does add is that it declines to do anything at all when the license reads as absent, because an unreachable license daemon is indistinguishable from an unlicensed system and re-rendering everything toward unlicensed over a transient socket failure would be far worse than leaving it alone -- one of those groups deletes its config file outright, and that file decides whether ctdb starts. failover.status is dropped from its cache ahead of the pass since half the groups read it while rendering, and truesearch is registered async so that waiting on its service job cannot hold the other consumers up behind it.
The cron template also goes back to rendering unless failover.status is definitively BACKUP. Keying it on SINGLE or MASTER instead, which is where it had drifted to, meant a transient ELECTING, IMPORTING or ERROR read emptied the whole schedule -- every user cronjob, rsync task, cloud sync, scrub and update check -- with nothing to put it back until the group happened to be regenerated again.
[llvm][AArch64] Fix callee-pops epilogue AUT (#211889)
When we combine local frame teardown with callee popped argument
cleanup, we need to pay special attention to what the SP was on entry so
that it can be used as the discriminator when AUT-ing a saved LR.
Refactors AArch64PointerAuthImpl::authenticateLR a bit to clean up the
logic that detects when we can either fold the AUT into the terminator
forming a RETA[AB][PC], or when we can hard-code the SP discriminator
into the AUT as in AUTI[AB]SP[PC].
[CIR] Add alias analysis skeleton (#214357)
This change adds the skeleton of MLIR alias analysis for CIR and
implements a very basic AA handler. More thorough AA implementations for
things like TBAA and restrict keyword handling will be added in the
future. This change is intended only to put the basic framework in
place.
Assisted-by: Claude / Sonnet-4.6
[CIR] Add cir.fmuladd op lowering to llvm.fmuladd (#215329)
Adds a new `cir.fmuladd` operation to the CIR dialect, modeling the
contractable fused multiply-add — `(a * b) + c` where the backend may
fuse into a single rounding step or not, at its discretion.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply at anthropic.com>
[CIR] Use dialect attr-name accessors and pin the coerce guard
Review feedback on #215117. The LLVM-dialect attribute names in
updateArgAttrs were spelled as string literals where mlir::LLVM::LLVMDialect
provides an accessor for each one and CIRGenCall.cpp already uses them.
Add a test for a pointer to member function, the case where the coercion type
already matches the original but the coercion is still needed.
Assisted-by: Cursor / claude-opus-5
[lldb] Fix misaligned pointer UB in DataExtractor::GetU16/U32/U64 array reads (#213038)
The multi-value overloads
`DataExtractor::GetU16`/`GetU32`/`GetU64(offset_ptr, dst, count)` extract `count` consecutive integers from the buffer. When the
data byte order differs from the host, they walked the source and destination
through typed pointers (`const uint16_t *`/`uint32_t *`/`uint64_t *`).
`GetData()` hands back a pointer to an arbitrary byte offset within the
underlying buffer, and the caller's destination is an arbitrary `void*`, so
neither is guaranteed to be aligned for the wider integer type. Casting
such a byte-offset pointer to a wider typed pointer, advancing it, and loading or
storing through it is undefined behavior even when the individual accesses go
through `memcpy`-based helpers, because the typed pointer itself is required to be aligned.
Compiling with UBSan's alignment check (`-fsanitize=alignment`) turns this UB
into a runtime diagnostic, for example:
```
runtime error: store to misaligned address 0x... for type 'uint16_t',
[9 lines not shown]
