[LAA][NFC] Refactor deref no-wrap check; expose broken reverse-loop bounds (#211960)
Split evaluatePtrAddRecAtMaxBTCWillNotWrap into two stages: compute
MaxOffset based on the step direction, then apply the shared
MaxOffset <= DerefBytes check.
Rename intermediate values to reflect what they actually represent.
This restructuring makes two long-standing off-by-EltSize issues in
the negative-step path explicit:
* The lower-bound check is over-conservative by EltSize.
* The upper-bound check under-counts by EltSize.
stat.2: enhance the description of st_blocks
Reviewed by: emaste, mckusick
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Differential revision: https://reviews.freebsd.org/D58592
[AMDGPU] gfx1250 co-execution scheduler
Snapshot of the gfx1250 co-execution scheduling work, squashed into a
single commit on top of llvm/llvm-project e2a39f504fee.
Includes the co-execution window model (AMDGPUCoExecInfo.h), the
CoExecSchedStrategy window-slot-demand machinery, pre-RA and post-RA
co-execution hazard tracking in GCNHazardRecognizer, the gfx1250 static
simulator (AMDGPUStaticSimulator), expert-mode waitcnt work in
SIInsertWaitcnts, and the supporting lit and MIR tests.
Authored by, in no particular order:
Austin Kerbow, Jeffrey Byrnes, Alexey Sachkov, Lucas Ramirez,
Volkan Keles, Hideki Saito, Jay Foad, Brendon Cahoon,
Ilia Cherniavskii, Alexander Weinrauch, Vigneshwar, proaditya,
mssefat, Lei Zhang
[AMDGPU] gfx1250 co-execution scheduler
Snapshot of the gfx1250 co-execution scheduling work, squashed into a
single commit on top of llvm/llvm-project 7570d2daec56.
Includes the co-execution window model (AMDGPUCoExecInfo.h), the
CoExecSchedStrategy window-slot-demand machinery, pre-RA and post-RA
co-execution hazard tracking in GCNHazardRecognizer, the gfx1250 static
simulator (AMDGPUStaticSimulator), expert-mode waitcnt work in
SIInsertWaitcnts, and the supporting lit and MIR tests.
Authored by, in no particular order:
Austin Kerbow, Jeffrey Byrnes, Alexey Sachkov, Lucas Ramirez,
Volkan Keles, Hideki Saito, Jay Foad, Brendon Cahoon,
Ilia Cherniavskii, Alexander Weinrauch, Vigneshwar, proaditya,
mssefat, Lei Zhang
clang: Emit "long-double-type" module flag generically
Move emission of the "long-double-type" module flag out of PowerPC
and into generic code, so it describes the long double format for all
targets.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
Keep container records unless their pool was really destroyed
## Problem
The container FS attachment delegate was the only stateful-workload delegate whose `delete()` destroyed configuration: it undefined the libvirt domain and removed the `container_container` and `container_device` rows, while deliberately leaving the rootfs dataset alone. VMs and apps only stop. That made `pool.export(cascade=True, destroy=False)` — the flow that exists precisely because the pool is moving elsewhere intact — permanently orphan live storage. A container's definition, devices and idmap slice live only in SQLite, nothing on disk can rebuild them (unlike the migrated incus containers, we write no manifest), and a freed idmap slice can be reissued to another container while the surviving rootfs still carries its UID range.
`pool.dataset.delete` reached the same code with no cascade flag at all, so deleting a dataset that a container merely bind-mounted as a FILESYSTEM device destroyed the whole container. And since `query()` only reports containers in ACTIVE_STATES, the cleanup was not even coherent — it dropped the records of running containers and kept those of stopped ones.
## Solution
- **`delete()` is now stop-only**, matching the VM and apps delegates. Records are never removed from the delegate.
- **Record removal moved to a `pool.post_export` hook**, which is the only place that can see whether the data actually went away. It keys off a new `destroyed` flag from `pool.export` rather than `options['destroy']`: asking to destroy an OFFLINE pool leaves it untouched on its disks, so the requested option on its own would still have discarded records whose storage was intact. The hook matches on the dataset and ignores runtime state, so stopped containers are cleaned up too.
- **Containers are re-pointed at their storage when a pool is imported under a new name.** The dataset is always `<pool>/.truenas_containers/containers/<name>`, so the new location is derived rather than guessed. The remap is committed only when the old pool is genuinely gone, the derived dataset exists, and no other container claims it; each container is applied behind its own boundary so one failure cannot abort the import or block the rest.
- **`pool.reimport` no longer starts everything on the pool.** It walks the delegates in start-priority order (it was using registration order, quietly defeating the docker/apps ordering) and calls a new `start_on_import`, which containers and VMs override to honour `autostart`. Previously every stopped container and VM on the pool came up regardless.
Also documents why `storage_paths()` derives the container root from the dataset name rather than its real mountpoint — both consumers need the name-derived form, and switching to the mountpoint would silently stop matching containers on pool export and lock.
Report apps whose config cannot be read instead of hiding them
## Problem
An app whose metadata is intact but whose saved configuration cannot be read was dropped from the collective metadata, which left it invisible to `app.query` and so impossible to delete - the same dead end this branch set out to remove, reached by a different route.
Separately, an app's metadata is only checked for the keys we need, never for what those keys hold. A value of a type we cannot use - an unquoted `1.13` that yaml parses as a float, a `portals` that is a string, a mapping key that is not a string at all - flows into the query result and raises somewhere further down. Since every app is built in one pass, that takes `app.query` down for every app on the system rather than just the one at fault.
## Solution
- **An app's metadata is recorded even when its config cannot be read**, so it stays visible and deletable, and the config read itself can no longer escape into the caller.
- **Metadata values are type-checked, not just counted.** A key which is absent is still defaulted exactly as before: metadata written by an older release must not be mistaken for a broken app, since being reported as broken takes away every operation but deletion.
- **Version comparison trusts neither side to be parseable**, portal URIs which cannot be normalised are passed through untouched, and the check for apps which disallow multiple instances no longer assumes an entry of the collective metadata is a mapping.
- **Each row is converted to an entry on its own**, so an app the API model cannot describe is reported the way any other broken app is - with a warning naming it - rather than failing the query for everything installed.
Keep container records unless their pool was really destroyed
## Problem
The container FS attachment delegate was the only stateful-workload delegate whose `delete()` destroyed configuration: it undefined the libvirt domain and removed the `container_container` and `container_device` rows, while deliberately leaving the rootfs dataset alone. VMs and apps only stop. That made `pool.export(cascade=True, destroy=False)` — the flow that exists precisely because the pool is moving elsewhere intact — permanently orphan live storage. A container's definition, devices and idmap slice live only in SQLite, nothing on disk can rebuild them (unlike the migrated incus containers, we write no manifest), and a freed idmap slice can be reissued to another container while the surviving rootfs still carries its UID range.
`pool.dataset.delete` reached the same code with no cascade flag at all, so deleting a dataset that a container merely bind-mounted as a FILESYSTEM device destroyed the whole container. And since `query()` only reports containers in ACTIVE_STATES, the cleanup was not even coherent — it dropped the records of running containers and kept those of stopped ones.
## Solution
- **`delete()` is now stop-only**, matching the VM and apps delegates. Records are never removed from the delegate.
- **Record removal moved to a `pool.post_export` hook**, which is the only place that can see whether the data actually went away. It keys off a new `destroyed` flag from `pool.export` rather than `options['destroy']`: asking to destroy an OFFLINE pool leaves it untouched on its disks, so the requested option on its own would still have discarded records whose storage was intact. The hook matches on the dataset and ignores runtime state, so stopped containers are cleaned up too.
- **Containers are re-pointed at their storage when a pool is imported under a new name.** The dataset is always `<pool>/.truenas_containers/containers/<name>`, so the new location is derived rather than guessed. The remap is committed only when the old pool is genuinely gone, the derived dataset exists, and no other container claims it; each container is applied behind its own boundary so one failure cannot abort the import or block the rest.
- **`pool.reimport` no longer starts everything on the pool.** It walks the delegates in start-priority order (it was using registration order, quietly defeating the docker/apps ordering) and calls a new `start_on_import`, which containers and VMs override to honour `autostart`. Previously every stopped container and VM on the pool came up regardless.
Also documents why `storage_paths()` derives the container root from the dataset name rather than its real mountpoint — both consumers need the name-derived form, and switching to the mountpoint would silently stop matching containers on pool export and lock.
net-p2p/amule: Use cryptopp-modern shared lib
security/cryptopp-modern 2026.8.0 builds with shared libs.
Let's use shared lib instead of previous static one.
