[offload][l0] Synchronize seed upload in `olMemFill` L0 slow path (#215270)
Fix Level Zero memory fills that cannot use
`zeCommandListAppendMemoryFill`, such as non-power-of-two patterns.
The replication fallback previously submitted a temporary host vector
whose lifetime could end before the asynchronous copy completed, which
caused unit test failures. This PR changes the replication fallback to
simply use `dataSubmit()` + `synchronize()` for the seed upload.
The software fill is also moved to L0SyncQueueTy so it's only possible
with a synchronous queue.
Assisted-by: Codex
[lldb] Add error handling of failed casts in DIL (#217431)
This patch does 2 things:
1. If `ValueObject::CastToBasicType` or `ValueObject::CastToEnumType`
return an ValueObject with an error, retrieve the error message and
return it as `DILDiagnosticError`.
2. Fix a minor bug in error checking logic in
`ValueObject::CastToBasicType`.
Rework snapshot rollback with batched destroys and bookmark support
## Problem
Rolling back past older snapshots destroyed the newer ones one ioctl at a time with no real pre-flight, so a hold or clone discovered midway left some snapshots already gone and, with `recursive_rollback`, a blocked child was only discovered after the parent had already been rolled back - a partially rolled-back tree. A newer bookmark blocked the rollback with an EEXIST that rendered as an empty conflict list plus advice (`recursive: true`) that provably could not help, since nothing could destroy bookmarks. Most kernel errors (ESRCH, EBUSY, EDQUOT, ENOSPC) were flattened into `ValidationError(EINVAL)` with a raw strerror, a rollback that had already committed was still reported as a failure when the follow-up zpool-history write failed, and a thick zvol rolled back across a volsize change silently lost its refreservation.
## Solution
- **Enumerate once, up front, for the whole tree.** Newer snapshots and bookmarks are collected for every affected dataset before anything is touched. Without `recursive`, the rollback is refused immediately with every conflict named - bookmarks included - and nothing destroyed; with it, hold/clone blockers are reported before any destroy, and a missing child snapshot fails the whole tree before the parent moves.
- **Batch the destroys.** All newer snapshots go in a single all-or-nothing ioctl per dataset, and newer bookmarks in another (via the new `lzc.get_bookmarks`/`lzc.destroy_bookmarks` pylibzfs bindings, which this change depends on). The kernel checks every object before destroying any, so a blocker - including the long holds from an in-flight send or a `.zfs/snapshot` automount that no pre-flight can see - destroys nothing and is named from the kernel's own error list. A destroy interrupted mid-sync (empty kernel error list) re-enumerates and reports honestly that an unknown number are already gone.
- **Honest error model.** Rollback failures get errno-specific messages; blockers and operational failures surface as `CallError` (EBUSY and friends) while input problems stay `ValidationError`; a committed rollback is never reported as a failure just because the zpool-history write raised afterwards; and any failure partway through a recursive rollback names the datasets that already rolled back, since that cannot be undone.
- **Restore a thick zvol's refreservation** after a rollback that changed the volsize, matching `zfs rollback`. Volumes with a synthetic (larger) refreservation are deliberately left alone, also matching `zfs rollback`.
- **Clones are always unmounted before being destroyed** - `force` now only selects how forcefully - and destroyed via `destroy_resource()`, fixing a path that previously crashed on a method that did not exist.
Fix TTL handling in cache.has_key and get_or_put
## Problem
`cache.has_key` returned True whenever the TDB record existed and never looked at the stored `timeout`, so it disagreed with `cache.get` — which expires the entry and raises `KeyError` — for any key that had expired but not yet been reaped. The only reaper is a 24h periodic with `run_on_start=False` whose timer is re-armed from scratch on every middlewared start, so on a box that restarts more often than daily it never runs at all and the wrong answer sticks around indefinitely.
Separately, `get_or_put` always stored `now + timeout`, so unlike `put` — where 0 means "never expires" — `get_or_put(key, 0, method)` stored an expiry of now and the entry was already expired on the very next read.
## Solution
`has_key` now delegates to `get()` and maps `KeyError` to False. Delegating rather than repeating the timeout comparison is deliberate: the bug existed because two methods independently decided what "expired" means, and this leaves only one. Expired entries are reaped on access as a side effect, which matters given how unreliable the periodic reaper is.
`get_or_put` stores a literal 0 when `timeout` is 0, matching `put`.
(cherry picked from commit 76a9e9c609461263bb81081647d23b242c73422c)
NAS-142457 / 27.0.0-BETA.1 / Fix TTL handling in cache.has_key and get_or_put (#19538)
## Problem
`cache.has_key` returned True whenever the TDB record existed and never
looked at the stored `timeout`, so it disagreed with `cache.get` — which
expires the entry and raises `KeyError` — for any key that had expired
but not yet been reaped. The only reaper is a 24h periodic with
`run_on_start=False` whose timer is re-armed from scratch on every
middlewared start, so on a box that restarts more often than daily it
never runs at all and the wrong answer sticks around indefinitely.
Separately, `get_or_put` always stored `now + timeout`, so unlike `put`
— where 0 means "never expires" — `get_or_put(key, 0, method)` stored an
expiry of now and the entry was already expired on the very next read.
## Solution
`has_key` now delegates to `get()` and maps `KeyError` to False.
Delegating rather than repeating the timeout comparison is deliberate:
the bug existed because two methods independently decided what "expired"
[7 lines not shown]
hwpmc tests: the sampling log file
Nine ATF cases covering PMC_OP_CONFIGURELOG and the descriptor-less
log operations: which descriptors are accepted, when a log is required
in the first place, and what the log operations do without one.
MFC after: 1 month
MFC to: stable/15
MFC to: stable/14
Assisted-by: Claude Code (Opus 5)
[AMDGPU] Reject image-load merges when either op has TFE/LWE (#210583)
## Summary
MIMG instructions with TFE or LWE enabled are now excluded during
mergeable candidate collection in `collectMergeableInsts()`, preventing
them from ever entering the merge candidate list in
`SILoadStoreOptimizer`.
## Problem
TFE (Texture Fetch Error) and LWE (Load Word Error) add status-result
semantics to image load instructions — the result register includes an
additional status word alongside the texture data. The image merge path
in `SILoadStoreOptimizer` does not reconstruct or represent these status
lanes. The previous eligibility logic in `dmasksCanBeCombined()` only
checked the leading instruction (`CI.I`) for TFE/LWE, which allowed the
asymmetric ordinary→TFE/LWE ordering to enter the merge path.
[41 lines not shown]
hwpmc: add credential-transition exec tests (keep and drop)
The companion to pmc_exec_test.c, which covers only the drop side of a
credential-changing exec. Three cases cover what the drop must not
overreach into: an exec that changes no credentials keeps the PMC, a
set-id exec whose credential change the kernel suppresses for a traced
target keeps it too, and a set-id fexecve(2) drops it. They exercise
the permission logic FreeBSD-SA-26:56.hwpmc reworked, not the defect
it fixed.
All three pass on a debug (INVARIANTS+WITNESS) kernel. The two
keep-cases were each observed to fail on a kernel mutated to detach
unconditionally.
MFC after: 1 month
MFC to: stable/15
MFC to: stable/14
Assisted-by: Claude Code (Opus 4.8)
hwpmc tests: process-attachment lifecycle and ownership cases
Seven ATF cases covering process-attachment teardown orderings: a
target that exits before it is detached, the owner that exits before
its target (hwpmc's other unlink path), releasing a still-running
attached PMC, row exhaustion with out-of-order release, and
PMC_F_DESCENDANTS inheritance including a fork storm.
All pass on a debug (INVARIANTS+WITNESS) and a KASAN kernel.
MFC after: 1 month
MFC to: stable/15
MFC to: stable/14
Assisted-by: Claude Code (Opus 5)
hwpmc: add tests for handle validation and the privilege boundaries
A pmc_id_t is a packed integer that the driver hands to userland and
accepts back on eleven operations, and nothing tested what happens when
one comes back forged, stale, or belonging to another process. Neither
was there a test that an unprivileged caller is refused the operations
that need a privilege.
The cases use a SOFT-class PMC wherever the counter itself does not
matter, so they run on a machine with no PMU.
MFC after: 1 month
MFC to: stable/15
MFC to: stable/14
Assisted-by: Claude Code (Opus 5)
hwpmc: add regression tests for a credential-changing exec
This tests what FreeBSD-SA-26:56.hwpmc fixed.
exec_setgid_drops_pmc asserts the kernel takes a process-mode PMC away
when its target execs a set-gid program its owner is not entitled to
trace.
exec_setuid_no_double_unlink lets the target exec a set-uid program;
the teardown must unlink the process descriptor exactly once, and
completing at all is the assertion.
Both need an unprivileged owner and must not drop privileges themselves,
since p_candebug() would then refuse the target to its own owner; they
ask for require.user instead.
MFC after: 1 month
MFC to: stable/15
MFC to: stable/14
Assisted-by: Claude Code (Opus 5)
[flang][OpenMP] Remove OmpVerifyModifiers
Verification of clause modifiers is now done in a single place.
The OmpVerifyModifiers function was left in place, but was reduced
to always return "true".
Remove the definition and all calls to it.
The large amount of apparent changes is mostly due to unindenting
and reformatting previously indented code.
[flang][OpenMP] Implement verification of modifier sets
Modifier sets and modifier groups are the modifier analogues of clause
sets and clause groups. In the OpenMP specification, modifier groups
have properties that are independent of the clause on which a member of
the group is specified, whereas modifier sets are local to clauses.
The implementation of modifier groups is identical to that of groups,
the only exception is that modifier sets don't have names that are
usable in diagnostic messages.
[flang][OpenMP] Replace modifier verification with common one
Since modifiers now have enum ids, verifying syntactical properties
of them no longer has to be type-based. Move the modifier verification
code out of a header file with some changes to use the numeric ids.
In addition to that, execute the verification for each clause from one
place. This PR still leaves the old verification calls in place, but the
OmpVerifyModifiers function returns true unconditionally. This is to
limit the amount of changes in this PR and will be cleaned up in a
subsequent PR.
Some form of a connection between AST nodes for modifiers and the enum
ids is still required, now it's a static member of the modifier AST node.
Fix TTL handling in cache.has_key and get_or_put
## Problem
`cache.has_key` returned True whenever the TDB record existed and never looked at the stored `timeout`, so it disagreed with `cache.get` — which expires the entry and raises `KeyError` — for any key that had expired but not yet been reaped. The only reaper is a 24h periodic with `run_on_start=False` whose timer is re-armed from scratch on every middlewared start, so on a box that restarts more often than daily it never runs at all and the wrong answer sticks around indefinitely.
Separately, `get_or_put` always stored `now + timeout`, so unlike `put` — where 0 means "never expires" — `get_or_put(key, 0, method)` stored an expiry of now and the entry was already expired on the very next read.
## Solution
`has_key` now delegates to `get()` and maps `KeyError` to False. Delegating rather than repeating the timeout comparison is deliberate: the bug existed because two methods independently decided what "expired" means, and this leaves only one. Expired entries are reaped on access as a side effect, which matters given how unreliable the periodic reaper is.
`get_or_put` stores a literal 0 when `timeout` is 0, matching `put`.
NAS-142027 / 27.0.0-BETA.1 / Stop treating an empty catalog as a valid catalog (#19537)
## Problem
`get_trains()` returns an empty mapping when `catalog.json` is missing
or unparseable, nothing prevents that from being cached for 25 hours,
and the cache-hit test only asked whether the entry was `not None` — so
an empty dict was served back as a legitimate hit. Every reader then
reads "no catalog data" as "nothing to update": apps report
`upgrade_available=false` with a null `latest_version`,
`upgrade_summary` refuses to upgrade any app, Discover shows nothing,
and the sync job reports SUCCESS while deleting `CatalogSyncFailed`,
`CatalogNotHealthy` and `AppUpdate` — a false all-clear that nothing
re-derives. The cache lives on tmpfs, so a poisoned entry survives a
middlewared restart and only clears on reboot. The
missing-`catalog.json` case logged nothing at all.
The cache key encoded only the catalog label, while the catalog location
flips between the apps dataset and a tmpfs path depending on whether
that dataset is mounted. `catalog.sync` and `catalog.apps` resolve the
[35 lines not shown]
[DirectX][Scalarizer] Make sure TargetTransformInfoWrapperPass is setup (#216893)
fixes #216888
In the process of testing the scalarization of HLSL long vectors I
discoved that some intrinsics were crashing when used with llc but not
when used with opt -scalarizer. This change makes sure that we have
setup TargetTransformInfoWrapperPass so that we can call the DirectX
versions of `isTargetIntrinsicWithScalarOpAtArg` and
`isTargetIntrinsicWithOverloadTypeAtArg`.
resolves https://github.com/llvm/llvm-project/issues/216191
Because we are also turning off the scalarizer if sm 6.9
Assisted by Copilot with GPT 5.6-Sol
