nfs_commonkrpc.c: Handle NFSERR_DELAY for Sequence correctly
Unlike RFC5661 (the original NFSv4.1 RFC), RFC8881 specifies
that a NFS4ERR_DELAY reply to the SEQUENCE operation requires
a reply using the same slot/sequence#.
This patch fixes handling of this case, so it conforms to
RFC8881.
(cherry picked from commit 6901cbbd5a2c00d378a7f87426b36d6ee6ce0aa2)
nfs_commonkrpc.c: Handle NFSERR_DELAY for Sequence correctly
Unlike RFC5661 (the original NFSv4.1 RFC), RFC8881 specifies
that a NFS4ERR_DELAY reply to the SEQUENCE operation requires
a reply using the same slot/sequence#.
This patch fixes handling of this case, so it conforms to
RFC8881.
(cherry picked from commit 6901cbbd5a2c00d378a7f87426b36d6ee6ce0aa2)
comms/klog: Update to 2.5.3
July 2026 - 2.5.3
- Bugfix: BandRX was not synced with FreqRX if FreqRX was not defined and BandRX was same as BandTX.
- Bugfix: Default DXCluster server is not shown in the combobox after first installation (Closes #1043)
- Enhancement: Color the QLineEdit that has the focus (Close #3) (TNX EA5WA)
- Enhancement: Move Comment field from Comment tab to QSO tab (Closes #1020) (TNX EA5WA)
- New feature: Selection of language (Closes #9) (TNX EA5WA)
- New feature: Set CQ zone from DXCC when adding QSO (TNX YL3GBC)
- New feature: Show a "New Locator" indicator when the DX locator is new on the current band or via satellite (Closes #1035) (TNX EA5WA)
- Translations: Latvian (TNX YL3GBC & YL3AUG)
[X86] Don't shrink VEX3 to VEX2 on a symbolic compare predicate (#213172)
`llvm-mc` asserts on a VCMP predicate given as a symbol:
```asm
vcmpps $f0, %xmm0, %xmm1, %xmm2
```
```
Assertion failed: isImm() && "This is not an immediate", MCInst.h:85
```
`optimizeInstFromVEX3ToVEX2` reads the predicate with `getImm()` to
decide whether the operands commute. A symbolic predicate is not known
until link time, so that decision cannot be made here. Decline the
shrink instead.
Unlike the sibling FPCLASS issues (#185364, #185365) this one is on the
encoding path and asserts under `--filetype=obj` too, so a release build
[6 lines not shown]
[RISCV] Fix assertion in combineBinOpOfExtractToReduceTree on type mismatch (#202201)
combineBinOpOfExtractToReduceTree asserts that the extract source
vector's element type equals the binop's value type
(SrcVecVT.getVectorElementType() == VT). This invariant does not hold
for all valid inputs.
A <1 x i1> binary operation under -mattr=+zve32x reaches this point with
the source vector element type differing from VT, which trips the
assertion in an assertions-enabled build and silently proceeds on a
false assumption otherwise.
Convert the assertion into an early return, so the combine declines when
its precondition is not met. This matches the existing bail-out style in
the same function (the isScalableVector and getScalarSizeInBits() >
getELen() checks immediately following). The change only ever skips the
fold; it never alters correct output.
Generative AI was used for the test case. The fix
[3 lines not shown]
