NAS-143004 / 26.0.0-RC.1 / Add private entitlements debug endpoint for debug bundles (by sonicaj) (#19608)
This commit adds changes to expose truenas.entitlements.debug_info, a
private method a debug bundle can call to see what an entitlement
decision was made from: the hardware facts, the raw license daemon
verdict that get_license() otherwise discards, the on-disk legacy
license as it actually is (a rejected or malformed blob currently reads
the same as no license at all) and every decision with the matrix column
it resolved to. Each section degrades to an error field rather than
raising, since the systems this is collected from are the ones whose
licensing is already misbehaving, and the legacy projection is an
allowlist so customer name and key never reach a bundle.
Original PR: https://github.com/truenas/middleware/pull/19598
Co-authored-by: Waqar Ahmed <waqarahmedjoyia at live.com>
NAS-143053 / 26.0.0 / Make VM and container UUID immutable after creation (by Qubad786) (#19604)
## Problem
`vm.update` and `container.update` accepted `uuid` and persisted it,
purely because the update models inherit the field from their create
models and never excluded it. In this system the UUID is not metadata,
it is the identity of the libvirt object: the domain XML writes it to
both `<name>` and `<uuid>` (the friendly name only lands in `<title>`),
and every lookup goes through `lookupByName(uuid)`. Neither `do_update`
touches libvirt, so changing the UUID rewrites one DB column and
re-points middleware at a domain that no longer exists — a running
instance reports STOPPED, which defeats the active-state guard in
`do_delete`, stop/suspend/reset raise `DomainDoesNotExistError`, a later
start defines a second domain over the same zvol or rootfs, and
container runtime mounts under the old UUID are orphaned. Worse, an
explicit `uuid: null` was not "leave it alone": it reached the
auto-generate branch in `validate()` and silently re-randomised a live
instance's identity.
[29 lines not shown]
NAS-143004 / 26.0.0 / Add private entitlements debug endpoint for debug bundles (#19598)
This commit adds changes to expose truenas.entitlements.debug_info, a
private method a debug bundle can call to see what an entitlement
decision was made from: the hardware facts, the raw license daemon
verdict that get_license() otherwise discards, the on-disk legacy
license as it actually is (a rejected or malformed blob currently reads
the same as no license at all) and every decision with the matrix column
it resolved to. Each section degrades to an error field rather than
raising, since the systems this is collected from are the ones whose
licensing is already misbehaving, and the legacy projection is an
allowlist so customer name and key never reach a bundle.
[flang][OpenMP] Implement modifier set and modifier group verification
Introduce modifier set and group definitions, and include that information
in clause descriptors.
Extend the verification of syntactic properties to handle sets and groups.
[flang][OpenMP] Replace modifier verification with a generic one
Implement verification of syntactic properties (i.e. required, unique,
exclusive, ultimate) in a generic way, agnostic of the kind of element
to which these properties are applied. The goal here is to reuse it
for verifying clause properties in the future.
Refactor the existing modifier verification code to use it. Modify
the previous implementation (OmpVerifyModifiers) to always succeed
to reduce the amount of necessary changes.
[flang][test] Expect a single -rpath in fveclib.f90 ArmPL check (#220969)
Fixes a `check-flang` failure on main: `Flang :: Driver/fveclib.f90`.
#220697 consolidated `tools::addArchSpecificRPath()` down to a single
call site — it was removed from `ToolChain::addFlangRTLibPath()` and
from the `-fveclib=ArmPL` block in `tools::AddLinkerInputs()`, and one
unconditional call was hoisted to the end of `AddLinkerInputs()`. A link
line can therefore emit each candidate rpath at most once, so
`CHECK-RPATH-ARMPL` fails on its second `-rpath` match:
```
flang/test/Driver/fveclib.f90:59:27: error: CHECK-RPATH-ARMPL-SAME: expected string not found in input
! CHECK-RPATH-ARMPL-SAME: "-rpath"
^
```
The two matches only ever passed because `addArchSpecificRPath()` is a
pure function of the toolchain and the argument list, so the two former
[10 lines not shown]
[offload][l0] Report actual driver version through OL_DEVICE_INFO_DRIVER_VERSION (#218412)
The Level Zero plugin currently reports the Level Zero API version as
the driver version. Moreover, as the lookup table only includes API
versions up to `1.12`, newer versions (e.g. `1.15`) end up being
reported as Unknown.
Report the actual driver version instead:
- If the `zeIntelGetDriverVersionString` extension is available, use it.
This string may be more detailed than what `zeDriverGetProperties`
provides (e.g. hotfix suffix)
- If the above is not available, use
`zeDriverGetProperties().driverVersion`, an U32 value whose octets make
up major, minor & build numbers.
- The driver version is fetched once per context and stored in an
`std::string` inside of the `L0ContextTy`.
This is intended to match the behavior of Intel's Unified Runtime.
[5 lines not shown]
[offload][sycl] Introduce `DRIVER_ID` device property (#217562)
Prior to the introduction of liboffload contexts, Level Zero devices
under different driver instances used to each receive their own
`L0ContextTy`s.
https://github.com/llvm/llvm-project/pull/209144 introduced contexts,
which are designed to map to a single `ze_context` on L0.
`olCreateContext` accepts a user-defined device list and is restricted
to accept devices within a single platform. This restriction is
insufficient for L0 - passing devices from different driver instances is
allowed under this contract, but does not make sense on L0 as
`zeContextCreate` needs a concrete driver instance as a parameter.
Introduce a `DRIVER_ID` device property. On CUDA and AMD, it is always
equal to 0. On L0, it is a distinct integer for each driver instance. A
set of devices can be used to create a context if and only if they all
belong to the same platform and have the same DRIVER_ID.
[4 lines not shown]
[VectorCombine] Check call targets when folding deinterleave/interleave pairs (#219116)
Instruction::isSameOperationAs() intentionally compares operation shape
and
special state without requiring operand identity. For CallBase
instructions,
this means calls to different targets with otherwise compatible
signatures can
compare as equivalent.
This caused VectorCombine::foldDeinterleaveInterleavePair() to treat
same-signature intrinsics such as llvm.smax and llvm.smin as the same
operation
and incorrectly fold them into a single widened call.
Add an opt-in Instruction::CompareCallTargets operation-equivalence
flag. When
requested, isSameOperationAs() additionally requires
CallBase::getCalledOperand() to match. Existing callers retain the
[9 lines not shown]
[Clang][OpenMP] Lower assume directive's holds clause to llvm.assume (#220688)
Emit `@llvm.assume` for the OpenMP 5.1 `assume` directive's `holds()`
clause, enabling downstream optimizations. Previously the clause was
parsed but its condition discarded without effect. Side-effectful
conditions are skipped with a warning, matching the existing
`[[assume]]`/`__builtin_assume` behavior.
nvme: limit namespace character-device I/O size
The namespace character device does not initialize si_iosize_max, so
physio falls back to DFLTPHYS and can produce a bio larger than the
qpair payload DMA tag on a controller whose maximum transfer size is
below 64KB. Such a bio fails DMA mapping and is never submitted.
Approved by: ngie (co-mentor)
MFC after: 1 week
Reviewed by: ngie, imp
Differential Revision: https://reviews.freebsd.org/D59152
nvme: complete requests when payload DMA mapping fails
bus_dmamap_load_mem() reports most mapping failures, including EFBIG,
only through its callback and then returns zero. nvme_payload_map()
logged the error without telling the submission path, so the tracker
stayed on the outstanding list with no command submitted and no
timeout armed, stalling all later I/O on the queue behind it.
Approved by: ngie (co-mentor)
MFC after: 1 week
Reviewed by: ngie, imp
Differential Revision: https://reviews.freebsd.org/D59151
[AMDGPU] PromoteAlloca: split scalar accesses that span several elements
promoteAllocaToVector already splits a *vector* access across several
elements when it is a multiple of the element size, but a *scalar* access
had to be bitcastable to the element type, so an i64 load from an alloca
promoted to <8 x i32> was rejected as "not a supported access type" and
the object stayed in scratch.
Accept a scalar access that is a whole multiple of the element size and
route it through the existing subvector path, which already builds the
value from consecutive elements and bitcasts. Accesses with padding are
still rejected, since splitting those would put the pieces at the wrong
offsets, as are non-integer non-float types.
[AMDGPU] PromoteAlloca: flatten homogeneous structs to vectors (#217055)
getVectorTypeForAlloca() peeled nested ArrayType and one inner
FixedVectorType, but stopped at any StructType. An alloca of an array of
structs was therefore rejected with "Cannot convert type to vector" and
fell back to scratch, even when the struct was a trivial wrapper around
a scalar.
Peel structs too, but only when every field has the same type and the
struct has no padding, so flattened elements keep the byte offsets the
surrounding index arithmetic assumes. Structs with differing field types
or with padding are left alone.
dnscontrol: Update to 5.0.3
Changelog
Provider-specific changes:
c1ebdb1: BIND: BUGFIX: SOA not incrementing on the existing zone (fixes #4840) (#4842) (@TomOnTime)
90984bb: BUNNY_DNS: Fix TXT record creation (#4839) (@TomOnTime)
c798fcb: LINODE: Add support for TTLs of 30s and 120s (#4835) (@dairiki)
f96fde4: LINODE: BUGFIX: too picky about hyphens in names of SRV records (#4828) (@TomOnTime)
Dependencies:
b6ce13f: CHORE: Update dependencies (#4843) (@TomOnTime)
Other changes and improvements:
34db875: BUG: SPF flattening removes redirect= modifiers that an "all" mechanism ignores (#4634) (@shuvamk)
0d6fe4b: CHORE: Upgrade to glob v1 (#4841) (@TomOnTime)
162a39b: Potential fix for code scanning alert no. 50: Cache Poisoning via execution of untrusted code (#4837) (@TomOnTime)
5196387: Release v5.0.3 (#4844) (@TomOnTime)
www/{nginx,nginx-devel,freenginx}: 3rd-party modules management
Chase the www/nginx-module-njs update to 1.0.1, which contains
security fixes. Bump PORTREVISION so the packages pick up the new
module.
Sponsored by: Netzkommune GmbH
