If the address of the isa_pointer is returned as an error don't ask if it is a tagged pointer (#213163)
The answer isn't right and the wrong type might stick and cause
downstream failures.
Note, the correct solution to this is to distinguish between "couldn't
get the address" and "got a real value of LLDB_INVALID_ADDRESS" but
piping an optional all the way down and then through all the uses is an
intrusive change which I don't have time for right now. That only risk
is that this really IS a tagged pointer with the value
LLDB_INVALID_ADDRESS, so this seems an acceptable workaround.
I ran across this when debugging the ObjC test failures in the ObjC
testuite after 8b9cce358bef26ae4cb9275dd6a43f903bafbaa0. This patch
clears up all those testsuite failures, which should stand as a test for
this patch when I resubmit that change.
[CIR] Implement most of 'musttail' statement attr (#213154)
This implements the basics, and leaves NYI in a few places (particularly
those that require cleanup calculations). There IS some additional work
that needs to be done when the ABI work is put in place as well, and the
thunk 'tail' hint isn't implemented either, and is left as a
missing-feature.
This is necessary for compiling the bytecode interpreter in Clang in a
few places during self-build.
[OpenMP][Offload] Fix use-after-free of the packed firstprivate transfer buffer (#212905)
`packAndTransfer()` called `submitData()`, which captured the address of
the data of
the `SmallVector` member of `PrivateArgumentManagerTy`, as the host
source of an
async transfer. The manager was later moved into an `AsyncInfo`
post-processing
lambda, changing the underlying address of the data:
`addPostProcessingFunction()`
copies the closure rather than moving it, but even if it "moved", the
address of the data owned by `SmallVector`'s inline capacity would have
changed.
The AMDGPU plugin read from the stale host source address when doing the
actual transfer.
Fix: allocate the packed buffer via
`getOrCreateSourceBufferForSubmitData()`, so
[2 lines not shown]
[lldb/docs] Document the remaining scripted-extension plugin categories (#213140)
`python_extensions.md` only covered the first five plugin categories.
This commit adds the missing sections for every plugin category added
since: `ScriptedBreakpointResolver`, `ScriptedHook`,
`ScriptedStackFrameRecognizer`, `ScriptedCommand`, `ParsedCommand`,
`ScriptedStringSummary`, and `ScriptedSyntheticChildren`.
Signed-off-by: Med Ismail Bennani <ismail at bennani.ma>
[lldb] Add target.jit-engine setting (#212998)
Add a target.jit-engine setting that lets users choose which LLVM
execution engine (MCJIT or ORC) is used to JIT expressions. Defaults to
MCJIT to preserve current behavior. This is groundwork for migrating
expression evaluation from MCJIT to ORC; IRExecutionUnit does not yet
consult this setting.
Relocate migrated container origins out of legacy .ix-virt
## Problem
Incus containers are ZFS clones of an image snapshot. The incus->container auto-migration relocated each container from `<pool>/.ix-virt/containers/<name>` to `<pool>/.truenas_containers/containers/<name>` with a bare `zfs rename` and did nothing else. A `zfs rename` does not change a clone's `origin`, so a migrated container stayed a clone of a snapshot still living inside `.ix-virt` - and deleting `.ix-virt` recursively destroyed those origin snapshots and cascaded into the dependent migrated clones, silently destroying migrated containers. The migration also left the legacy parents mounted, moved on without a license, gave up on every remaining pool when one failed, and could leave a container renamed into the native tree with no database row pointing at it.
## Solution
Relocate each container's origin image out of `.ix-virt` before renaming the container, so no migrated container depends on anything under `.ix-virt`, and make the surrounding migration and deletion paths recoverable.
- **Shared relocation helper** - `relocate_container_origin` reads a container's live `origin`; if it points at an image under `.ix-virt/images` or `.ix-virt/deleted/images`, it sets `canmount=noauto` on that image dataset and then renames it into the native `.truenas_containers/images/` tree. The rename goes last so it is the single atomic commit point: the image is either wholly still in `.ix-virt` or wholly relocated, and the return value describes reality. Fan-out clones auto-repoint on the rename; an origin outside `.ix-virt` is left alone; a container that is a clone of another container is refused, since the two would arrive entangled.
- **Migration path** - the migration calls the helper immediately before renaming each container and skips any container whose base image cannot be relocated, rather than producing one that looks healthy until `.ix-virt` is deleted.
- **Repair migration** - new `0020_repair_incus_clone_origins` runs the same relocation over existing `container.container` rows for systems that already ran the old migration, and restores the legacy parents' mountpoint those runs left inherited.
- **Leave the legacy tree as found** - mount properties are reverted on any container that is not migrated, and the legacy parents are restored at the end of every run, so nothing is left mounted under `/mnt/<pool>/.ix-virt` with nothing managing it. Both reverts are armed before the properties are touched, since a partial apply has to be reverted too.
- **Migration robustness** - the migration is skipped on HA capable hardware and deferred (leaving the legacy configuration intact) when the system is not licensed for containers; one unusable pool no longer stops the pools after it; and a container whose dataset was renamed but whose row was never created is moved back where the user can see it.
- **Safer deletion** - the libvirt domain is torn down first so the container's runtime mounts are gone before ZFS is touched, the dataset is destroyed next, and the database records are removed only once it is confirmed gone - so a failed destroy never orphans the dataset with no row pointing at it. An already-missing dataset is tolerated so a container whose data was lost to the old cascade can still be removed cleanly.
- **Active-instance guards** - deleting or renaming a container that is not stopped (running or suspended) is refused; delete additionally accepts `force=True`, mirroring the VM delete flow, and is now a job locked per container id. The container status model gains the `SUSPENDED` state it has always been able to report.
audio/sox: Unbreak build when no audio devices are selected
Upstream allows this configuration so the port should as well.
PR: 297173
Approved by: Dan Nelson (maintainer)
Relocate migrated container origins out of legacy .ix-virt
## Problem
Incus containers are ZFS clones of an image snapshot. The incus->container auto-migration relocated each container from `<pool>/.ix-virt/containers/<name>` to `<pool>/.truenas_containers/containers/<name>` with a bare `zfs rename` and did nothing else. A `zfs rename` does not change a clone's `origin`, so a migrated container stayed a clone of a snapshot still living inside `.ix-virt` - and deleting `.ix-virt` recursively destroyed those origin snapshots and cascaded into the dependent migrated clones, silently destroying migrated containers. The migration also left the legacy parents mounted, moved on without a license, gave up on every remaining pool when one failed, and could leave a container renamed into the native tree with no database row pointing at it.
## Solution
Relocate each container's origin image out of `.ix-virt` before renaming the container, so no migrated container depends on anything under `.ix-virt`, and make the surrounding migration and deletion paths recoverable.
- **Shared relocation helper** - `relocate_container_origin` reads a container's live `origin`; if it points at an image under `.ix-virt/images` or `.ix-virt/deleted/images`, it sets `canmount=noauto` on that image dataset and then renames it into the native `.truenas_containers/images/` tree. The rename goes last so it is the single atomic commit point: the image is either wholly still in `.ix-virt` or wholly relocated, and the return value describes reality. Fan-out clones auto-repoint on the rename; an origin outside `.ix-virt` is left alone; a container that is a clone of another container is refused, since the two would arrive entangled.
- **Migration path** - the migration calls the helper immediately before renaming each container and skips any container whose base image cannot be relocated, rather than producing one that looks healthy until `.ix-virt` is deleted.
- **Repair migration** - new `0020_repair_incus_clone_origins` runs the same relocation over existing `container.container` rows for systems that already ran the old migration, and restores the legacy parents' mountpoint those runs left inherited.
- **Leave the legacy tree as found** - mount properties are reverted on any container that is not migrated, and the legacy parents are restored at the end of every run, so nothing is left mounted under `/mnt/<pool>/.ix-virt` with nothing managing it. Both reverts are armed before the properties are touched, since a partial apply has to be reverted too.
- **Migration robustness** - the migration is skipped on HA capable hardware and deferred (leaving the legacy configuration intact) when the system is not licensed for containers; one unusable pool no longer stops the pools after it; and a container whose dataset was renamed but whose row was never created is moved back where the user can see it.
- **Safer deletion** - the libvirt domain is torn down first so the container's runtime mounts are gone before ZFS is touched, the dataset is destroyed next, and the database records are removed only once it is confirmed gone - so a failed destroy never orphans the dataset with no row pointing at it. An already-missing dataset is tolerated so a container whose data was lost to the old cascade can still be removed cleanly.
- **Active-instance guards** - deleting or renaming a container that is not stopped (running or suspended) is refused; delete additionally accepts `force=True`, mirroring the VM delete flow, and is now a job locked per container id. The container status model gains the `SUSPENDED` state it has always been able to report.
if_gre(4): Fix link state announcement in SIOCDIFPHYADDR
Since we unlock gre before if_detach() and use slock in gre_clone_modify_nl()
there is no need to split if_link_state_change() out of gre_delete_tunnel().
Reported by: markj
Fixes: a0d2e5ebaa2e ("if_gre(4): Fix races by changing initialization order and locks")
[SandboxVectorizer] Implement topdown/bottomup vectorizers in unison (#205249)
Extend the Sandbox Vectorizer's `bottom-up-vec` pass so a single
implementation can vectorize in either direction, and add the top-down
strategy that walks def-use chains forward from a seed.
Direction selection
--------------------
The pass direction is chosen from the Region's auxiliary pass argument:
"bottom-up" (or empty, the default) and "top-down" map onto a
SchedDirection, and any other value is rejected with a fatal usage
error.
The vectorizer always runs in the same direction as the scheduler.
Top-down traversal
------------------
Bottom-up starts from a seed slice (e.g. stores to consecutive
addresses)
and recurses into operands. Top-down instead starts from a seed of
[40 lines not shown]
[SandboxVec][DAG] Fix notifyEraseInstr to skip scheduled neighbors (#212868)
Guard both loops with !PredN->scheduled() so scheduled neighbors are
left untouched, and add a unit test that erases a node with one
scheduled and one unscheduled predecessor to cover the fix.
Merge tag 'for-linus-iommufd' of git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd
Pull iommufd fixes from Jason Gunthorpe:
"Several bug fixes found by tools and fuzzing:
- Incorrect domain passed during replace to ack faults
- Block the access API from using dmabuf
- Missing unlock on error unwind
- Race seeing a partially setup vdevice in the xarray
- Do not allow vdevices to have multiple stream ids in SMMUv3
- Possible UAF if racing faults with domain changes"
* tag 'for-linus-iommufd' of git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd:
iommu/iommufd: Fix IOPF group ownership UAF
[5 lines not shown]
Update to 0.33
Upstream changes:
0.33 Thu Apr 16 13:59:10 JST 2026
- Fixed a build issue on Windows, reported by
Thomas.Eckardt [...] thockar.com
0.32 Wed Apr 15 14:52:28 JST 2026
Applied a series of patches from cpan [...] schmirler.de
(https://rt.cpan.org/Public/Bug/Display.html?id=175921):
- Crypt::SMIME now requires OpenSSL 3.0 or newer.
- Decryption: Handle the new smime-type value "authEnveloped-data"
in isEncrypted().
- Encryption: Add an optional "cipher" argument to encrypt(...),
defaulting to "AES-128-CBC" as before. Pass e.g. "AES-128-GCM" to
encrypt with a modern AEAD cipher.
- Signing: To tell a peer that we support AEAD ciphers we should
advertise them in the SMIMECapabilities signed attribute. As of
OpenSSL 3.5 AES-GCM is not part of the default list. Now we
advertise AES-256-GCM, AES-128-GCM, AES-256-CBC, and AES-128-CBC.
[8 lines not shown]
Merge tag 'audit-pr-20260730' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit
Pull audit fixes from Paul Moore:
- Fix potential integer overflows in audit_log_n_string()
Similar to the earlier fix to audit_log_n_hex() that you merged
earlier in July. Expect a cleaner, and generally better fix for these
functions in an upcoming merge window, but this addresses the problem
in a small patch that should be easy for people to backport.
- Fix potential use-after-free in audit_del_rule()
* tag 'audit-pr-20260730' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit:
audit: fix potential use-after-free in audit_del_rule()
audit: fix potential integer overflow in audit_log_n_string()
[BOLT] Fix RELR addend updates for non-zero image bases (#213000)
This patch fixes an AArch64 BOLT failure exposed by LLVM commit
`fbba327208d7f6994f9a28a51dca3e913e3b444a`, which enabled packed
relative relocations (RELR) globally. BOLT incorrectly used a virtual
relocation address as a file offset when updating RELR addends,
corrupting instrumented executables when their image base was non-zero.
The observed CMake compiler-check failure was only a consequence of the
corrupted BOLT-instrumented Clang executable crashing; the defect itself
is in BOLT, not CMake.
The regression test links an AArch64 PIE with a non-zero image base and
verifies that BOLT updates the RELR addend at the correct file offset.
Assisted-by: Codex
