X86: Mark EFLAGS dead on MOV32r0 emitted outside SelectionDAG
Currently these get set by LiveVariables after the fact, but
ideally we would not rely on that since it's long overdue for
deletion.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
AMDGPU: Remove deprecated getArchAttr and ArchFeatures TableGen
Everything should now use getFeatureBitset*
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
AMDGPU: Migrate R600 onto generated TargetParser bitset
Follow the new amdgcn system so we don't have to carry 2 different
forms of this infrastructure.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
[CIR] Drop res_attrs when a rewritten return has no result
An Indirect return moves the value to an sret pointer argument the pass
inserts, and an Ignore return drops it, so the rewritten func or call
has no result for the per-result `res_attrs` array to describe. The
function rewrite and both call rewrites now remove it.
Assisted-by: Cursor / claude-opus-5
ZIO: Batch lightweight ZIOs
This further develops concept of ZIO batching from #18921, extending
it from the leaf vdev layer up the stack. Now it covers the case of
I/O scheduler enabled, not covered before. I/O aggregation of the
scheduler can complete several ZIOs at once, creating opportunity
for batching.
This change allows ZIO pipeline stages to return more than one ZIO,
chaining them via the field added in previous commit, renaming it
to more generic io_exec_next. To identify ZIOs to batch, this change
introduces a new ZIO flag ZIO_FLAG_LIGHTWEIGHT, set for members of
a batch. So once zio_done() or possibly other stage handlers return
a list of ZIOs, zio_execute() has now ability to decide which of them
to execute itself, and which to dispatch to taskqueues as before.
With this change my tests of 32KB block writes to 3x 5-wide NVMe RAIDZ1
on 64-core system with scheduler=on show throughput increase from
15.0GiB/s to 16.1GiB/s, while the taskqueue lock contention is
[12 lines not shown]
[SandboxVec][VecUtils] Introduce DeadInstrMorgue
Move dead instructions collector and erasor into VecUtils, so that
it is usable by both, BundleVec and LoadStoreVec, vectorizers. NFC
[mlir] Migrate aggregate builders to explicit properties
Pass typed property structs and discardable attributes separately at ODS
aggregate builder call sites. Preserve direct FIR callees and cover call
property and discardable attribute preservation in FIR and Func lowering.
Assisted-by: Codex
NAS-143516 / 26.0.0-RC.1 / rename the s3 service from truenas_s3 to s3 (by anodos325) (#19673)
service.query reported it as truenas_s3, the daemon's name rather than
the protocol's. The services_services row has to move with
ServiceInterface.name or nothing resolves it, so a migration renames it;
ServiceWriteRole is keyed by the name upper-cased and moves too.
Root is refused as an access key account and as a bucket owner. Both run
as uid 0, which no bucket grant and no file mode restrains.
The daemon's own messages get /var/log/truenas_s3.log, filtered on the
journal identifier it writes, s3d, and rotated the way scst and
truenas-discoveryd are. Its audit records are a separate path and are
untouched.
The systemd unit, the etc group and the tables keep the truenas_s3 name:
they are the daemon's, and nothing outside middleware names them.
Original PR: https://github.com/truenas/middleware/pull/19672
Co-authored-by: Andrew Walker <andrew.walker at truenas.com>
libjail: fix fetching mac.label for multiple jails
When doing a basic `jls -n`, jls(8) will jailparam_get() the mac.label
for every jail on the system using the same set of jailparams, and thus
the same jp_value. We only init the mac_t the first time, so the first
jail would populate it with `?` from /etc/mac.conf and the resulting
jail_get(2) would clobber it with the empty string, then a second jail
would try to pass the empty string to the kernel and fail because it
must have a non-zero length.
Fix it by invoking jps_get() every time. Drop some comments to note
that jps_get() will be invoked with zero || garbage from previous call,
and be sure that we don't leak our previous mac_t. There aren't any
other jps_get implementations at this time, so this shouldn't cause any
unexpected problems.
Reported by: ivy
Reviewed by: jamie
Differential Revision: https://reviews.freebsd.org/D57280
rename the s3 service from truenas_s3 to s3
service.query reported it as truenas_s3, the daemon's name rather than
the protocol's. The services_services row has to move with
ServiceInterface.name or nothing resolves it, so a migration renames it;
ServiceWriteRole is keyed by the name upper-cased and moves too.
Root is refused as an access key account and as a bucket owner. Both run
as uid 0, which no bucket grant and no file mode restrains.
The daemon's own messages get /var/log/truenas_s3.log, filtered on the
journal identifier it writes, s3d, and rotated the way scst and
truenas-discoveryd are. Its audit records are a separate path and are
untouched.
The systemd unit, the etc group and the tables keep the truenas_s3 name:
they are the daemon's, and nothing outside middleware names them.
(cherry picked from commit 70df33ef4679699b48eea3fbc41f45c1224045b8)
NAS-143516 / 26.0.0-RC.1 / rename the s3 service from truenas_s3 to s3 (#19672)
service.query reported it as truenas_s3, the daemon's name rather than
the protocol's. The services_services row has to move with
ServiceInterface.name or nothing resolves it, so a migration renames it;
ServiceWriteRole is keyed by the name upper-cased and moves too.
Root is refused as an access key account and as a bucket owner. Both run
as uid 0, which no bucket grant and no file mode restrains.
The daemon's own messages get /var/log/truenas_s3.log, filtered on the
journal identifier it writes, s3d, and rotated the way scst and
truenas-discoveryd are. Its audit records are a separate path and are
untouched.
The systemd unit, the etc group and the tables keep the truenas_s3 name:
they are the daemon's, and nothing outside middleware names them.
x[SystemZ][z/OS] Correctly align the constant pool and the PPA1
Both should be half-word aligned. However, testing revealed that
both can end up on odd addresses, which leads to relocation errors.
Fix is to change the alignment.
