[AArch64] Canonicalize NVCAST to bitcast under LE (#223388)
A NVCAST is equivalent to a BITCAST under LE. This canonicalises the
NVCAST to BITCAST under LE like we do for ARM, so there is only one
representation, then fixes up the places that were assuming nvcast.
NAS-143385 / 27.0.0-BETA.1 / Create `IncusVirtualMachinesWereNotMigratedAlert` if there still are some Incus VM datasets (#19680)
Additionally, `maybe_migrate_legacy` was removed from the private API
because no one calls it.
arm64: don't consult mvfr1_el1 for AArch64 fp capabilities
The MVFR1_EL1 register describes features for the AArch32 AdvSIMD and FP
implementation and the contents of this register are UNKNOWN when FEAT_AA32
is not implemented.
So let's ignore this register and just set FPCR defaults for IEEE 754
compatibility.
Before this change, 7 tests in lib/libm failed on a VMware Fusion VM
(Apple M4 Pro) where MVFR1_EL1 reads as zero. With this change, all
tests pass.
[OpenMP][OMPT] Fixes current_address printing on RV64GC (#223681)
A previous commit increased the number of arguments passed to printf in
print_possible_return_addresses(addr) but forgot to change the format in
order to include the new argument.
Fixes: 4e19543b1a85 (FIX some OMPT tests that fail on RISC-V (#156914),
2026-07-24)
[BOLT] Prevent rela.plt reordering (#219447)
[BOLT] Preserve the original order of DT_JMPREL relocations.
BOLT reorders .rela.plt entries without also updating the corresponding
PLT stub relocation indices. This patch preserves the original order of
DT_JMPREL relocations by recording their original indices and using
those indices when emitting them. We store the original `DT_JMPREL`
index directly on each relocation.
AI tools (codex) were used to assist with implementation.
Related to https://github.com/llvm/llvm-project/issues/207222
[offload] add handling of memory alignment to MemoryManagerTy (#218418)
Previously, memory alignment was handled internally by the device. The
`MemoryManagerTy` either redirected large allocation requests directly
to the device or stored pointers to the smaller memory chunks in pools.
The information about the alignment expected by the user was just passed
by the `MemoryManagerTy` to the device allocators. However, most vendors
do not provide an API for specifying the alignment of the memory
allocation (except for the Level Zero plugin), allowing only for
verification of whether the returned pointer is correctly aligned. In
this patch, `MemoryManagerTy` allocates excess memory and performs
pointer arithmetic on the pointer returned by the device allocator, so
that the final pointer is aligned accordingly regardless of the plugin.
NodeTy has two new fields:
- `BasePtr`: the pointer to the originally allocated memory
- `Ptr`: the pointer returned to the caller, possibly after pointer
arithmetic operations on `BasePtr` for ensuring the requested alignment.
[13 lines not shown]
Run the unit tests against a single middlewared tree
## Problem
`tests/run_unit_tests.py` copied the checkout's `middlewared/pytest` into the installed package so that dotted imports like `middlewared.pytest.unit.entitlements` would resolve, then collected the tests from the checkout anyway. Test modules were loaded by path from the checkout while everything they imported came from `/usr/lib/python3/dist-packages`. The alert applicability tests decide whether an alert class is product code or a test fixture by where its file lives, so the three fixtures in `test_lifecycle.py` were counted as product declarations and the frozen inventory no longer described the tree, failing the `unit_tests` pipeline (http://jenkins-eng-ci.cmb1.ixsystems.net:8080/job/master/job/unit_tests/355/). The copy was also removed afterwards, and since the deb ships `middlewared/pytest`, every run left the installed package missing files it is supposed to have.
## Solution
Drop the copy and prepend the checkout's `src/middlewared` to `sys.path`, so the tests and the `middlewared` they import are one tree. That is the layout the GitHub Actions run and the documented inventory-regeneration command already use, and it makes the earlier two-tree tolerance in `test_applicability_matrix.py` unnecessary, so that goes back to a single prefix.
Worth noting on review: the job now exercises the checkout's Python rather than the installed deb's. It was never a clean artefact test -- it already ran the checkout's test modules against whatever product code was installed -- and the frozen inventory is generated from the checkout, so the checkout is the only tree it can meaningfully be compared against.
NAS-143333 / 27.0.0-BETA.1 / Gate SED on TrueNAS hardware with a licensed feature key (#19684)
This PR adds changes to restrict SED to TrueNAS hardware carrying a
license with the SED feature key, and to have that enforced.
The SED vector becomes `ce=0, hw=0, hw_l=0, hw_k=1, ce_l=0, ce_k=0` and
SED is injected into legacy licenses so the existing installed base
keeps it. Those two have to land together: narrowing the vector on its
own would deny every legacy licensee whose bitmask never carried the SED
bit, and their pools would stop unlocking on upgrade. The injection is
unconditional because the hardware conjunct lives in the vector, not in
the license parser, which stays a pure function of the blob it is
handed. This supersedes the earlier decision that allowed the keyless
grants.
Enforcement goes through a new `validate_sed_license` shaped after the
existing `validate_dedup_license`, wired into pool create, update,
attach and replace. Setting a global or per-disk SED password is gated
too, though clearing one always works so a system that lost the
[15 lines not shown]
Require a SED feature key on TrueNAS hardware
This commit adds changes to narrow the SED entitlement so it only resolves on TrueNAS hardware carrying a license with the SED feature key, and to inject that key into legacy licenses so the existing installed base keeps working. Both halves have to land together: narrowing the vector on its own would deny every legacy licensee whose bitmask never carried the SED bit, and their pools would stop unlocking on upgrade. The injection is unconditional because the hardware conjunct lives in the vector, not in the license parser, which stays a pure function of the blob it is handed. This supersedes the earlier decision that allowed the keyless grants.
(cherry picked from commit 3dcdeb8181a66d8e578d1232773d0135c6350f8e)
Require a SED feature key on TrueNAS hardware
This commit adds changes to narrow the SED entitlement so it only resolves on TrueNAS hardware carrying a license with the SED feature key, and to inject that key into legacy licenses so the existing installed base keeps working. Both halves have to land together: narrowing the vector on its own would deny every legacy licensee whose bitmask never carried the SED bit, and their pools would stop unlocking on upgrade. The injection is unconditional because the hardware conjunct lives in the vector, not in the license parser, which stays a pure function of the blob it is handed. This supersedes the earlier decision that allowed the keyless grants.
(cherry picked from commit 3dcdeb8181a66d8e578d1232773d0135c6350f8e)
NAS-143333 / 27.0.0-BETA.1 / Gate SED on TrueNAS hardware with a licensed feature key (#19684)
This PR adds changes to restrict SED to TrueNAS hardware carrying a
license with the SED feature key, and to have that enforced.
The SED vector becomes `ce=0, hw=0, hw_l=0, hw_k=1, ce_l=0, ce_k=0` and
SED is injected into legacy licenses so the existing installed base
keeps it. Those two have to land together: narrowing the vector on its
own would deny every legacy licensee whose bitmask never carried the SED
bit, and their pools would stop unlocking on upgrade. The injection is
unconditional because the hardware conjunct lives in the vector, not in
the license parser, which stays a pure function of the blob it is
handed. This supersedes the earlier decision that allowed the keyless
grants.
Enforcement goes through a new `validate_sed_license` shaped after the
existing `validate_dedup_license`, wired into pool create, update,
attach and replace. Setting a global or per-disk SED password is gated
too, though clearing one always works so a system that lost the
[12 lines not shown]
nginx: Update to 1.30.5
Changes with nginx 1.30.5 15 Sep 2026
*) Security: a heap memory buffer overflow might occur in a worker
process under certain configurations when using HTTP/3 with OpenSSL
3.5.0 and earlier (CVE-2026-90439).
Thanks to Banny Liao.
*) Change: now the QUIC transport parameters extension received in an
SSL connection is always ignored.
[lldb][Windows] Support AF_UNIX domain sockets (#205618)
Enable the Windows `AF_UNIX` domain-socket support added in #205864 by
flipping the `#if LLDB_ENABLE_POSIX` guards to `#if LLDB_ENABLE_POSIX ||
defined(_WIN32)`.
Also updates `SocketTest.cpp` to exercise `ProtocolUnixDomain` on
Windows (while still excluding ProtocolUnixAbstract, which has no
Windows equivalent).
This is part of a longer set of patches to fix tests on
`LLDB_USE_LLDB_SERVER=1`.
Share the SED entitlement check between its callers
This commit makes some changes where the SED entitlement check was written out by hand in a few places instead of going through one helper. `validate_sed_license` moves out of the pool utilities, since nothing about it is pool specific, and takes the key to report under as a single string so a settings field validator can pass a bare field name while the pool paths keep passing a full schema path.
The global SED password is now checked by a field validator like everything else in advanced settings, rather than inline ahead of them, so a denial no longer pre-empts the other errors in the same payload. That needed the password merged into the dicts the settings helper diffs, because it is not a field on the entry, and it lets the helper go back to its original signature.
Enforce the SED entitlement on pool and password paths
This commit adds changes to actually enforce the SED rule, which until now was checked almost nowhere — creating a pool with the all_sed flag had no entitlement check at all. Pool create, update, attach and replace now go through a shared validate_sed_license, and setting a global or per-disk SED password is gated too, though clearing one always works so a system that lost the entitlement can still drop a secret it is no longer allowed to use.
Unlock is deliberately left ungated. A license daemon that errors with anything other than "no license" reads as unlicensed, so gating unlock would turn a daemon hiccup into a failed pool import at boot and a failed unlock on an HA master transition. The drives are already provisioned by that point, so unlocking them grants nothing new. What this enforces is no new SED usage, rather than no SED usage at all.
Report SED gate denials consistently and exclude sed in v26
This commit fixes a few problems found while reviewing the SED gates. `sed` is now excluded from the disk update model in v26 as well as v27, because stable/26 serves v26 as its current version and the two have to agree; a `from_previous` hook would not have helped, since the adapter validates a payload against the client's own model before it adapts anything.
The license denial in pool attach now raises before the disk lookup that can throw and discard it, and the global SED password denial accumulates into the same batch as the other advanced settings validators rather than pre-empting them, which needed an optional accumulator on the settings helper. The KMIP tests mock the SED entitlement because they set a global SED password to reach the escrow path.
Reject undetermined disks from all-SED pools
This commit fixes an issue where the disk SED capability column is tri-state but every consumer compared it with `is False`, so a disk that had never been probed passed the "must be SED" check and could join an all-SED pool unnoticed. The comparisons now reject anything that is not definitively SED. It also excludes `sed` from the disk update model, since it is a hardware fact we probe rather than something a caller has any business writing.
Require a SED feature key on TrueNAS hardware
This commit adds changes to narrow the SED entitlement so it only resolves on TrueNAS hardware carrying a license with the SED feature key, and to inject that key into legacy licenses so the existing installed base keeps working. Both halves have to land together: narrowing the vector on its own would deny every legacy licensee whose bitmask never carried the SED bit, and their pools would stop unlocking on upgrade. The injection is unconditional because the hardware conjunct lives in the vector, not in the license parser, which stays a pure function of the blob it is handed. This supersedes the earlier decision that allowed the keyless grants.
WebAssembly: Drive Emscripten EH from the exception model, drop the cl::opt
Remove the deprecated -enable-emscripten-cxx-exceptions flag. This should now
be driven by the generic exception-model mechanisms. There was also some special
case handling of the -mllvm flag in the clang driver which also needed removal.
Also reverts the test change in b6912258891caefffbf15edb1bceff3724b75af5 now that
the backend doesn't need to be built to test the flag behavior.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
RuntimeLibcalls: Read exception model from the module flag
Source the exception model in the RuntimeLibcallsInfo(Module) constructor
from the "exception-model" module flag via Module::getExceptionModel(),
instead of forwarding it from TargetOptions. An absent flag resolves to
Default and then to the triple default; an explicit "none" disables
exceptions.
Since the model now comes from the module, drop the ExceptionModel that
RuntimeLibraryAnalysis carried and forwarded, and its argument at every
construction site.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
CodeGen: Read the exception model from the module flag in EH lowering
Resolve the exception model as the exception-model module flag if
present, otherwise the TargetOptions default.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
