NAS-140418 / 26.0.0-BETA.2 / fix R50BM rear nvme drive bays (by yocalebo) (#18640)
Platform team gave me access to an internal R50BM that was 100% verified
to be configured according MPI. It was installed with 24.10.2 (and NO
that's not a typo for the version). The rear nvme drive bays do NOT get
wired up properly. This is a long convoluted story but the gist is that
4 years when we added this platform the system that was used to test
these changes was NOT configured according to the MPI that we have
currently. Investigation is still ongoing internally to make sure we
don't have a kernel change causing slot mappings to be wonky but for
now, these changes 100% fix the rear nvme drive bay mapping issue.
Original PR: https://github.com/truenas/middleware/pull/18635
Co-authored-by: caleb <yocalebo at gmail.com>
NAS-140418 / 25.10.2.2 / fix R50BM rear nvme drive bays (by yocalebo) (#18638)
Platform team gave me access to an internal R50BM that was 100% verified
to be configured according MPI. It was installed with 24.10.2 (and NO
that's not a typo for the version). The rear nvme drive bays do NOT get
wired up properly. This is a long convoluted story but the gist is that
4 years when we added this platform the system that was used to test
these changes was NOT configured according to the MPI that we have
currently. Investigation is still ongoing internally to make sure we
don't have a kernel change causing slot mappings to be wonky but for
now, these changes 100% fix the rear nvme drive bay mapping issue.
Original PR: https://github.com/truenas/middleware/pull/18635
Co-authored-by: caleb <yocalebo at gmail.com>
NAS-140418 / 26.0.0-BETA.1 / fix R50BM rear nvme drive bays (by yocalebo) (#18639)
Platform team gave me access to an internal R50BM that was 100% verified
to be configured according MPI. It was installed with 24.10.2 (and NO
that's not a typo for the version). The rear nvme drive bays do NOT get
wired up properly. This is a long convoluted story but the gist is that
4 years when we added this platform the system that was used to test
these changes was NOT configured according to the MPI that we have
currently. Investigation is still ongoing internally to make sure we
don't have a kernel change causing slot mappings to be wonky but for
now, these changes 100% fix the rear nvme drive bay mapping issue.
Original PR: https://github.com/truenas/middleware/pull/18635
Co-authored-by: caleb <yocalebo at gmail.com>
clang: Stop assuming one toolchain covers all GPUArchs
Previously there was a vector of toolchains, but a number of
places assumed there was only a single toolchain. I'm also not
sure how you were supposed to identify which toolchain to use from
this array. Make this parallel to the stored GpuArches. For
the fat binary cases, we still need to pick a toolchain so that
still just picks the first one; it probably should use
the most neutral available triple.
This also doesn't feel like a complete fix. The various Actions
all contain a reference to an OffloadingToolChain, which seems
to frequently be missing and isn't set at construction time.
[CIR] Auto-generate matchAndRewrite for one-to-one CIR-to-LLVM lowerings (#190326)
When a CIR op specifies a non-empty `llvmOp` field, the lowering
emitter now generates the `matchAndRewrite` body that converts the
result type and forwards all operands to the corresponding LLVM op.
This removes 27 boilerplate lowering patterns from LowerToLLVM.cpp.
Ops needing custom logic (FMaxNumOp/FMinNumOp for FastmathFlags::nsz)
override `llvmOp = ""` to retain hand-written implementations.
Also fixes llvmOp names (TruncOp -> FTruncOp, FloorOp -> FFloorOp)
and adds a diagnostic rejecting conflicting llvmOp + custom constructor.
[clang] Fixed a crash when explicitly casting to atomic complex (#172163)
Fixed a crash when explicitly casting a scalar to an atomic complex.
resolve: #114885
NAS-140418 / 27.0.0-BETA.1 / fix R50BM rear nvme drive bays (#18635)
Platform team gave me access to an internal R50BM that was 100% verified
to be configured according MPI. It was installed with 24.10.2 (and NO
that's not a typo for the version). The rear nvme drive bays do NOT get
wired up properly. This is a long convoluted story but the gist is that
4 years when we added this platform the system that was used to test
these changes was NOT configured according to the MPI that we have
currently. Investigation is still ongoing internally to make sure we
don't have a kernel change causing slot mappings to be wonky but for
now, these changes 100% fix the rear nvme drive bay mapping issue.
NAS-140520 / 26.0.0-BETA.2 / Pass caller privilege context to debug generation for correct job visibility (by Qubad786) (#18637)
## Problem
When generating a system debug, `jobs.json` contains only 2-3 jobs
instead of the full set. This happens because ixdiagnose was calling
`privilege.become_readonly()` before all API calls to ensure Secret
field redaction in debug output.
The issue is that `become_readonly()` drops the credential from
FULL_ADMIN to READONLY_ADMIN, which has two effects: (1) Secret fields
are redacted in API responses (intended), and (2)
`credential_is_limited_to_own_jobs()` in `core.get_jobs` activates
per-user job filtering (unintended side effect). Since the ixdiagnose
middleware client is a freshly created session that owns no jobs, the
result is nearly empty — only jobs with explicit `read_roles` (like
`replication.run`) survive the filter.
This affects all users regardless of privilege level because ixdiagnose
[32 lines not shown]
NAS-140520 / 26.0.0-BETA.1 / Pass caller privilege context to debug generation for correct job visibility (by Qubad786) (#18636)
## Problem
When generating a system debug, `jobs.json` contains only 2-3 jobs
instead of the full set. This happens because ixdiagnose was calling
`privilege.become_readonly()` before all API calls to ensure Secret
field redaction in debug output.
The issue is that `become_readonly()` drops the credential from
FULL_ADMIN to READONLY_ADMIN, which has two effects: (1) Secret fields
are redacted in API responses (intended), and (2)
`credential_is_limited_to_own_jobs()` in `core.get_jobs` activates
per-user job filtering (unintended side effect). Since the ixdiagnose
middleware client is a freshly created session that owns no jobs, the
result is nearly empty — only jobs with explicit `read_roles` (like
`replication.run`) survive the filter.
This affects all users regardless of privilege level because ixdiagnose
[32 lines not shown]
NAS-140520 / 27.0.0-BETA.1 / Pass caller privilege context to debug generation for correct job visibility (#18632)
## Problem
When generating a system debug, `jobs.json` contains only 2-3 jobs
instead of the full set. This happens because ixdiagnose was calling
`privilege.become_readonly()` before all API calls to ensure Secret
field redaction in debug output.
The issue is that `become_readonly()` drops the credential from
FULL_ADMIN to READONLY_ADMIN, which has two effects: (1) Secret fields
are redacted in API responses (intended), and (2)
`credential_is_limited_to_own_jobs()` in `core.get_jobs` activates
per-user job filtering (unintended side effect). Since the ixdiagnose
middleware client is a freshly created session that owns no jobs, the
result is nearly empty — only jobs with explicit `read_roles` (like
`replication.run`) survive the filter.
This affects all users regardless of privilege level because ixdiagnose
[27 lines not shown]
[CIR] Fix record layout for [[no_unique_address]] fields (#186701)
Fix two bugs in CIR's handling of `[[no_unique_address]]` fields:
- Record layout: Use the base subobject type (without tail padding)
instead of the complete object type for [[no_unique_address]] fields,
allowing subsequent fields to overlap with tail padding.
- Field access: Insert bitcasts from the base subobject pointer to the
complete object pointer after cir.get_member for potentially-overlapping
fields, so downstream code sees the expected type.
- Zero-sized fields: Handle truly empty [[no_unique_address]] fields by
computing their address via byte offsets rather than cir.get_member,
since they have no entry in the record layout.
A known gap (CIR copies 8 bytes where OG copies 5 via
`ConstructorMemcpyizer`) is noted for follow-up.
[lldb] Load scripts from code signed dSYM bundles (#189444)
LLDB automatically discovers, but doesn't automatically load, scripts in
the dSYM bundle. This is to prevent running untrusted code. Users can
choose to import the script manually or toggle a global setting to
override this policy. This isn't a great user experience: the former
quickly becomes tedious and the latter leads to decreased security.
This PR offers a middle ground that allows LLDB to automatically load
scripts from trusted dSYM bundles. Trusted here means that the bundle
was signed with a certificate trusted by the system. This can be a
locally created certificate (but not an ad-hoc certificate) or a
certificate from a trusted vendor.
[BOLT] Check for write errors before keeping output file (#190359)
Summary:
When the disk runs out of space during output file writing, BOLT would
crash with SIGSEGV/SIGABRT because raw_fd_ostream silently records write
errors and only reports them via abort() in its destructor. This made it
difficult to distinguish real BOLT bugs from infrastructure issues in
production monitoring.
Add an explicit error check on the output stream before calling
Out->keep(), so BOLT exits cleanly with exit code 1 and a clear error
message instead.
Test: manually verified with a full filesystem that BOLT now prints
"BOLT-ERROR: failed to write output file: No space left on device" and
exits with code 1.
build fix
In NetBSD 11 and possibly also SmartOS the ar 'l' modifier went from
l This modifier is accepted but not used.
to
l Specify dependencies of this library.
so ar clq went to "not working"; remove the l and reorder to
"command first, modifier after" and it'll build again.
Test-built on netbsd-11 and netbsd-10
[LV] Only create partial reductions when profitable. (#181706)
We want the LV cost-model to make the best possible decision of VF and
whether or not to use partial reductions. At the moment, when the LV can
use partial reductions for a given VF range, it assumes those are always
preferred. After transforming the plan to use partial reductions, it
then chooses the most profitable VF. It is possible for a different VF
to have been more profitable, if it wouldn't have chosen to use partial
reductions.
This PR changes that, to first decide whether partial reductions are
more profitable for a given chain. If not, then it won't do the
transform.
This causes some regressions for AArch64 which are addressed in a
follow-up PR to keep this one simple.
