Don't use SCSI_DATA_IN for patrol read commands that don't have a data
buffer. Noticed while looking into crashes reported by job@ but doesn't
fix anything.
ok dlg@
[CycleInfo] Identify cycles with a single-pass DFS algorithm (#210491)
Replace the Havlak-Tarjan construction in GenericCycleInfoCompute, a DFS
followed by a reverse-preorder scan, with the single-pass algorithm of
Wei, Mao, Zou and Chen, "A New Algorithm for Identifying Loops in
Decompilation" (SAS 2007). One depth-first traversal tags every block
with its innermost loop header on the fly; tagLoopHeader weaves the
per-block header chains, replacing UNION-FIND.
The flat forest is reconstructed from the tags, dropping the temporary
cycle objects and the per-block worklist passes. An edge re-entering an
already-closed cycle records non-header entries, so entries need no
predecessor scan.
The cycle sets, headers, reducibility and nesting are identical for the
given DFS order, cross-checked against the old construction on random
reducible and irreducible CFGs. Two implementation-defined orders change
(with minor test churn): sibling cycles are laid out in decreasing
header preorder, and non-header entries in block preorder.
[6 lines not shown]
Revert "[flang][OpenMP] Fix new metadirective-loop-nest.f90 test expectation with collapse changes in #208528" (#210860)
Reverts llvm/llvm-project#210753
Revert with #208528 pending llvm-test-suite fix.
nfsd: Optionally enable use of M_EXTPG mbufs for read replies
A test site determined that, for a Mellanox NIC which can handle
M_EXTPG mbufs, an improvement of 5-15% for read rate could be
achieved if the read reply was in M_EXTPG mbufs.
A patch that tried to determine if the outbound NIC supported
M_EXTPG mbufs (IFCAP_MEXTPG) did not pass review.
However, it does appear that this can be useful for NFS-over-RDMA.
(Which just happen to use NICs that do support M_EXTPG mbufs.)
As such, this patch enables them is xp_extpg is set to true,
which is never for now, but might be set true for RDMA or
when vfs.nfsd.enable_mextpg is set non-zero. (It is 0 by
default, so this is never enabled by default at this time.)
(cherry picked from commit d516e52373e1768ea84bf1ca220671a44f413abe)
[Clang][AIX] Switch -mloadtime-comment-vars name matching to mangled IR names
Replace source-qualified name matching in matchesLoadTimeCommentVarName with
mangled IR symbol name matching via getMangledName(GlobalDecl(VD)).
[ProfileData] Refactor SampleProfileNameTable into a polymorphic class hierarchy (NFC) (#210252)
This patch refactors SampleProfileNameTable into an abstract base
class with concrete derived classes like LazySampleProfileNameTable
and EagerSampleProfileNameTable.
The motivation is twofold:
- I want each derived class to focus on one data representation
instead of using complex if-then-else. Plus, I'm planning to
introduce one more data representation [1].
- I want each class to be populated and ready for use as soon as it is
constructed. That is, there is no intermediate state like
"constructed but waiting to be populated".
Now, you might notice that the iterator uses virtual operator[]. I
would argue that this is acceptable. We have three places where we
iterate over the entire range of the name table entries. Two of
[8 lines not shown]
zfs recv: warn when a non-raw incremental diverges a raw IV set
A non-raw incremental received onto a snapshot that was itself received
raw re-stamps the destination's IV set guid with a fresh value, so it no
longer matches the sending lineage. Nothing rejects this at the time,
but a later raw incremental taken from that snapshot is rejected with an
IV set guid mismatch (#8758). The failure surfaces arbitrarily later,
often on a different host, with no hint that an earlier non-raw receive
was the cause.
The receive itself cannot tell that a snapshot was received raw from
anything on disk: a raw-received snapshot and an ordinary locally-keyed
one both carry an IV set guid of the same shape, one stamped from the
stream and one from unique_create(), with no recorded provenance. So
warning on every non-raw incremental into an encrypted dataset would
fire on the common keys-local backup workflow that never hits the bug.
Record the provenance instead. A raw receive now stamps a
DS_FIELD_RAW_RECEIVED marker on the new snapshot, next to the ivset
[23 lines not shown]
libzfs: clarify the raw incremental "IV set guid mismatch" error
When a raw incremental receive is rejected because the IV set guid of
the incremental source snapshot does not match the send stream, the
error only said "IV set guid mismatch" and pointed at the man page.
That leaves the user with no idea what actually happened or how to
recover, which is a recurring complaint in #8758: the state that
triggers the error is created silently, most commonly by a single
non-raw incremental receive in an otherwise raw chain (e.g. a
replication tool falling back or omitting -w once). Such a receive
copies the dataset guid from the stream but re-encrypts the data with
a freshly generated IV set, so the destination snapshot looks
identical to guid-matching tools while any later raw incremental based
on it must be rejected to avoid mixing two incompatible ciphertext
lineages.
Name the non-raw-receive cause and the recovery (roll the destination
back to the most recent raw-received snapshot and take the raw
incremental from there, or receive a new full raw stream) directly in
[14 lines not shown]
ZTS: assert the IV set guid divergence behind mixed raw/non-raw sends
send_mixed_raw already exercises the failing sequence from #8758: a
raw full receive, then a non-raw incremental receive, then a raw
incremental receive that is rejected with "IV set guid mismatch".
However it only asserted the final failure, not the mechanism, so a
regression in how receives stamp the IV set guid could go unnoticed
as long as something still failed.
Extend the test to pin down the actual state transitions:
- A raw receive must preserve both the dataset guid and the IV set
guid of the received snapshot.
- A non-raw incremental receive copies the dataset guid from the
stream but generates a fresh IV set guid on the destination. This
is the silent divergence that later raw incrementals trip over:
the snapshots look identical to guid-matching tools while their
IV sets no longer match.
[14 lines not shown]
[TableGen] Add sub-register overflow tests for exact-fit and non-covered registers (#210529)
Follow-up to #206346. Adds two cases the overflow check's companion test
missed: an exact-fit tiling that must be accepted, and a register
without `CoveredBySubRegs` that must be left alone. Test only.
man: conditionally install pam_zfs_key.8
When built with --enable-pam include the pam_zfs_key.8 man
page, otherwise omit it. This aligns man/Makefile.am with
the build logic in contrib/Makefile.am.
Signed-off-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Closes #18815
Closes #18817
[NFC][SLP] Precommit tests for ordered fadd-reduction FMA-fusion cost (#210835)
Baseline coverage for an ordered fadd-of-fmul reduction that is
currently vectorized even on FMA-capable targets, breaking the scalar
fmul + fadd -> fma fusion. A follow-up teaches the reduction cost model
to account for the lost fusion and keep these reductions scalar, at
which point these CHECK lines update. Covers X86 avx2, AMDGPU gfx90a and
NVPTX sm_80.
It is a pre-requisite for
https://github.com/llvm/llvm-project/pull/210399
Assisted-By: Claude Opus 4.8
[docs] Clean up migrated Clang InternalsManual markup
Replace migrated blockquote markup in InternalsManual.md with MyST definition lists where the surrounding text is semantically a term-and-definition list.
