[LoongArch][NFC] Replace manual v2i128 check with MVT::v2i128 (#241726)
Now that v2i128 is a legal MVT, the manual v2i128 check and the
associated stale comment are no longer needed. Compare against
MVT::v2i128 directly instead.
[libc][test] Fix dangling CString paths in copy_file_range_test (#241787)
Fixes the `aarch64` / overlay failure in
`libc.test.src.unistd.copy_file_range_test` introduced by #240018.
### Root Cause
1. `libc_make_test_file_path(...)` returns an owning `CString`
(non-copyable, non-movable). Storing it into `const char *in_path` /
`out_path` in `SetUp()` destroyed the temporary `CString` immediately,
leaving dangling pointers for `open()` and `unlink()` and causing
`ENOENT` in `SetUp()` (cascading into `EBADF` in `CopyNoOffsets` and
`CopyWithOffsets`).
2. `LlvmLibcCopyFileRangeTest::SetUp()` and `TearDown()` overrode
`ErrnoCheckingTest::SetUp()` / `TearDown()` without invoking the base
class methods.
### Changes
- Initialize `in_path` and `out_path` directly as fixture members using
`decltype(libc_make_test_file_path(...))` so the `CString` objects stay
[8 lines not shown]
[flang] Fix incorrect reallocation for host-associated main-program coarrays #231233 (#233361)
This fix resolves the issue #231233 involving incorrect reallocation of
a coarray when it is accessed via host association in a nested
procedure.
---------
Co-authored-by: Dan Bonachea <dobonachea at lbl.gov>
[Hexagon] Add local VTCM frames for HLX objects (#241650)
Move local HLX objects to a separate VTCM frame, address them through
VSP, and allocate and release the frame with vallocframe and
vdeallocframe.
Co-authored-by: Yashas Andaluri <yandalur at qti.qualcomm.com>
[flang][Semantics] Adding check integer kind on STAT= specifier #230463 (#231103)
This PR adds a pedantic warning to check whether the specified STAT is
an integer of at least 16-bit because
flang currently silently accepts 8-bit integers to `STAT=`: and F2023
9.7.4 says:
> R946 _stat-variable_ is _scalar-int-variable_
>
> A stat-variable should have a decimal exponent range of at least four;
otherwise the
> processor-dependent error code might not be representable in the
variable.
[SPIRV] Keep source location on OpAsmCallINTEL
insertInlineAsmProcess builds OpAsmCallINTEL with a MachineIRBuilder
whose debug location is empty.
The call therefore had no location, so the NonSemantic
debug handler emitted no debug line information.
sysutils/libmbus: [NEW PORT] Meter-bus library and utility programs
The Meter-Bus is a standard for reading out meter data from
electricity meters, heat meters, gas meters, etc. The M-bus
standard deals with both the electrical signals on the M-Bus,
and the protocol and data format used in transmissions on
the M-Bus. The role of libmbus is to decode/encode M-bus
data, and to handle the communication with M-Bus devices.
WWW: https://github.com/rscada/libmbus/
PR: 298095
Co-authored by: alven@
[Clang][NFC] Re-enable consumed analysis test for chained logical OR (#240849)
Re-enable the three-way logical OR test in `testComplexConditionals1` by
removing its `#if 0` guard and stale FIXME. The operands start in the
unknown consumed state. Keep all six existing expected warnings in the
true and false branches unchanged.
Prepared with assistance from Codex.
[Clang][NFC] Re-enable local-class static member diagnostic test (#240834)
Re-enable the local-class static data member example in
`clang/test/SemaTemplate/instantiate-static-local.cpp`. Keep its
existing `expected-error {{static}}`, remove the `#if 0` guard and stale
crash FIXME, and remove the conflicting `expected-no-diagnostics`
marker.
The crash was fixed by e2def106757534b07a2d3ff15ddd48e14b69a66d
(#182707). A targeted AArch64 snapshot search followed by native X86
assertions-on builds confirms the boundary: the parent
c1c4a5a870eb668fec480771c4d002e17362ed18 crashes in
`LocalInstantiationScope::findInstantiationOf` on both attempts, while
the fix emits only the expected illegal-static-member diagnostic and
exits normally on both attempts.
Prepared with assistance from Codex.
NAS-145210 / 27.0.0 / Keep encryption keys loaded on zfs.resource.unmount by default (by Qubad786) (#20200)
## Problem
`zfs.resource.unmount` documents `unload_encryption_key` as defaulting
to `False`, but `unmount_impl` only passed it to truenas_pylibzfs when
it was `True`. truenas_pylibzfs defaults it to `True`, so every unmount
of an encryption root unloaded its key, and a recursive unmount did the
same for every encryption root below it. A later `zfs.resource.mount`
then failed with "encryption key not loaded" (e.g. ix-apps after a
docker stop, or a container dataset left behind by migration).
## Solution
Always pass `unload_encryption_key` to truenas_pylibzfs so the caller's
value is honoured. The lock path already passes `True` explicitly, so
its behaviour is unchanged. Added an integration test that recursively
unmounts a parent with an encrypted child and checks the child's key
survives and it can be mounted again.
Original PR: https://github.com/truenas/middleware/pull/20189
Co-authored-by: M. Rehan <mrehanlm93 at gmail.com>
NAS-145210 / 27.1.0 / Keep encryption keys loaded on zfs.resource.unmount by default (by Qubad786) (#20201)
## Problem
`zfs.resource.unmount` documents `unload_encryption_key` as defaulting
to `False`, but `unmount_impl` only passed it to truenas_pylibzfs when
it was `True`. truenas_pylibzfs defaults it to `True`, so every unmount
of an encryption root unloaded its key, and a recursive unmount did the
same for every encryption root below it. A later `zfs.resource.mount`
then failed with "encryption key not loaded" (e.g. ix-apps after a
docker stop, or a container dataset left behind by migration).
## Solution
Always pass `unload_encryption_key` to truenas_pylibzfs so the caller's
value is honoured. The lock path already passes `True` explicitly, so
its behaviour is unchanged. Added an integration test that recursively
unmounts a parent with an encrypted child and checks the child's key
survives and it can be mounted again.
Original PR: https://github.com/truenas/middleware/pull/20189
Co-authored-by: M. Rehan <mrehanlm93 at gmail.com>
NAS-145153 / 27.1.0 / Fail graceful VM and container stop when the guest keeps running (by Qubad786) (#20202)
## Problem
A graceful `vm.stop` / `container.stop` (no `force`, no
`force_after_timeout`, the API default) waited `shutdown_timeout` and
then reported SUCCESS even when the guest ignored the shutdown request
and was still running. The UI showed the guest as stopped and a graceful
container restart then failed on start with "already started". A
suspended VM was also left suspended with a successful job, even with
`force_after_timeout`, because the post-stop check only looked for
`RUNNING`.
## Solution
After the shutdown request, both stop paths check the state again. If
the guest has not stopped, it is powered off when `force_after_timeout`
is set; otherwise the job fails with an ETIMEDOUT `CallError` saying it
did not stop within the timeout. A suspended VM is resumed before the
shutdown request so the guest can act on it, and library errors (e.g.
stopping a guest that is not running) are raised as `CallError` like
[5 lines not shown]
NAS-145155 / 28.0.0-BETA.1 / Harden container image pull (#20188)
## Problem
Pulling a container image leaked raw `requests` errors, had no timeout
on the tarball download so a stalled stream hung forever and never
checked the published sha256. The pull was a sync job, so it could only
stop at its own abort checks, and `container.create` wasn't abortable at
all. Two concurrent pulls of the same uncached image could also destroy
each other's in-progress dataset through the orphan cleanup.
## Solution
- **Readable registry errors**: registry index failures (connection,
HTTP status, timeout, bad JSON) are raised as `CallError('Failed to
query container image registry: ...')`.
- **aiohttp with timeouts**: the registry fetch and tarball download use
aiohttp with connect and per-read timeouts of `INTERNET_TIMEOUT` and no
total limit, so a stall fails the pull instead of hanging. `trust_env`
is set so the `http(s)_proxy` environment is still honoured, as it was
with `requests`.
[22 lines not shown]
[CIR] Use `cir.vec.fcmp` op for AArch64 builtins (#241404)
I've been splitting integer and floating comparisons and stumbled upon
these.
claude updated the test.
Harden container image pull
## Problem
Pulling a container image leaked raw `requests` errors, had no timeout on the tarball download so a stalled stream hung forever and never checked the published sha256. The pull was a sync job, so it could only stop at its own abort checks, and `container.create` wasn't abortable at all. Two concurrent pulls of the same uncached image could also destroy each other's in-progress dataset through the orphan cleanup.
## Solution
- **Readable registry errors**: registry index failures (connection, HTTP status, timeout, bad JSON) are raised as `CallError('Failed to query container image registry: ...')`.
- **aiohttp with timeouts**: the registry fetch and tarball download use aiohttp with connect and per-read timeouts of `INTERNET_TIMEOUT` and no total limit, so a stall fails the pull instead of hanging. `trust_env` is set so the `http(s)_proxy` environment is still honoured, as it was with `requests`.
- **Checksum**: the download is hashed as it streams and compared against the registry's sha256 before anything is extracted.
- **Registry lookup first**: the image/version lookup happens before `ensure_datasets`, the orphan destroy and the dataset create, so an unknown image or unreachable registry never touches a dataset. Cached images still return early without network access.
- **Async pull**: `container.image.pull` is an async job, so an abort cancels the network awaits immediately. File writes go through a thread, and progress is only reported when the integer percent changes.
- **Threaded extraction**: the tarball is streamed through `tarfile` in a thread that checks for abort before every member and raises `JobCancelledException`, so a partial rootfs is never snapshotted. On any failure or cancel the cleanup awaits the extraction thread until it has stopped and only then destroys the image dataset, since destroying it while the thread is still writing fails as busy.
- **Abortable create**: `container.create` is `abortable=True`. It forwards the abort to its pull job, because `job.wrap` doesn't cancel the subjob, and raises `JobCancelledException` if the pull was aborted on its own.
- **Per-image lock**: `container.image.pull` holds a lock keyed on pool, name and version with `lock_queue_size=None`, so each create waits for its own pull job and a waiter after a successful pull hits the cached snapshot.
